fix: add unaffected results to db search vuln, fix alias results

[kzantow]

This PR makes some fixes to grype db search and grype db search --include-aliases to get a more appropriate set of records.

Currently, in Grype matching there are many factors that affect whether a package is deemed vulnerable and often the determination requires information from multiple sources such as GHSA and SUSE to avoid false positives. If a user is trying to get details about a specific vulnerability, we need to include unaffected records and aliases to get most of the big picture about what's going on.

To see all* the records that will impact a particular package, we need unaffected records and to go 2 levels deep in aliases.

Take the newly added GO vulnerabilities, for example: GO-2026-5005. If I run:

$ grype db search --vuln GO-2026-5005
VULNERABILITY  PACKAGE              ECOSYSTEM  NAMESPACE             VERSION CONSTRAINT  
GO-2026-5005   golang.org/x/crypto  go-module  govulndb:language:go  <0.52.0

Perfect: I see there's just a single record with a version constraint.

But wait... let's say I don't see that result but I'm using something that looks like version 0.50.0 -- how can I figure out what's going on?

Previously --include-aliases would include a single-level of aliases, so db search --vuln GO-2026-5005 --include-aliases would find a single alias for the GO-2026-5005 record: CVE-2026-39833 and include both of those results. But there are more records that will come into play, especially: GHSA-jppx-rxg9-jmrx -- perhaps there are corrected version ranges or a vendor has asserted that this particular package is not vulnerable for their distributed version of the package. Previously, you wouldn't see any information about this because it's a second-level alias: no alias information exist directly from the GO vuln to the GHSA vuln but both of these alias to CVE-2026-39833, so --include-aliases needs to account for this.

Additionally, vulnerabilities may be filtered by entries in the unaffected packages set, which are stored in a separate table and not returned by affected packages queries. This PR adds the records to db search with an (unaffected) label at the end of the constraint to indicate Grype will match against that range as an unaffected filter rather than a vulnerable range. This is probably the part that needs the most discussion.

We need to be able to correctly identify records should be considered unaffected in both the table and in JSON output. The current implementation in this PR is just to get a discussion started and looks something like:

% grype db search CVE-2024-27282
VULNERABILITY   PACKAGE                                      ECOSYSTEM  NAMESPACE                               VERSION CONSTRAINT                                                      
CVE-2024-27282  cpe:2.3:a:ruby-lang:ruby:*:*:*:*:*:ruby:*:*  ruby       nvd:cpe                                 < 3.0.7 || >= 3.1.0, < 3.1.5 || >= 3.2.0, < 3.2.4 || >= 3.3.0, < 3.3.1  
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:14.04                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:16.04                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:18.04                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:20.04                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:23.10                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:24.04                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:25.10                                                                                      
CVE-2024-27282  jruby                                        deb        ubuntu:distro:ubuntu:26.04                                                                                      
CVE-2024-27282  libruby2_1-2_1                               rpm        sles:distro:sles:12.2                   (unaffected)                                                            
CVE-2024-27282  libruby2_1-2_1                               rpm        sles:distro:sles:12.4                   = 3.0.1 (unaffected)                                                            
CVE-2024-27282  libruby2_1-2_1                               rpm        sles:distro:sles:12.5                   (unaffected)                                                            
CVE-2024-27282  libruby2_5-2_5                               rpm        sles:distro:sles:15                     (unaffected)                                                            
CVE-2024-27282  libruby2_5-2_5                               rpm        sles:distro:sles:15.1                   (unaffected)                                                            
CVE-2024-27282  libruby2_5-2_5                               rpm        sles:distro:sles:15.2                   <= 3.05 (unaffected)     
...

I think ideally we would instead include a status column and these would be Not-Affected / Unaffected or similar. There is a VulnerabilityStatus on the data model which is seems to be unset some of the time but appears to be the right spot for this to be conveyed, however: adding records with an unknown new status might result in them being interpreted as vulnerable by consumers. Grype itself only considered withdrawn and rejected to be "not vulnerable" types of statuses.

All that said, without this information, db search is very difficult to use to understand the scope of grype's matching about a particular vulnerability. We need a a way of displaying this information to users, ideally without needing to remember to execute multiple queries to get enough pertinent information. It's pretty confusing when searching for a vulnerability only to find it looks like something different should be happening.

* still not necessarily all

[kzantow]

Notes from team discussion:

• add a separate unaffected top-level list to the data model so the JSON
• the (unaffected) to the table seems to be acceptable