Improve vulnerability matching to consider potentially multiple resolutions

[ckunki]

Class VulnerabilityMatcher currently identifies vulnerabilities by package name and ID.

In reality, however,

• for a given package & version,
• there could be multiple unique vulnerability issues.
• Each vulnerability might be resolved in multiple ways

Summary:

• 1 (package-version combination): m (vulnerabilities)
• m (vulnerabilities): n (resolved package-version combinations)

The current ticket therefore requests to

• enhance the matching strategy of class VulnerabilityMatcher
• Update tests and documentation accordingly -> think doc/user_guide/features/managing_dependencies.rst does not need to be updated

[ArBridgeman]

Here is an example where one package cryptography==46.0.5 has two vulnerabilities with a different minimum fix version.

Output is from nox session dependency:audit:

[
  {
    "name": "cryptography",
    "version": "46.0.5",
    "refs": [
      "CVE-2026-34073",
      "GHSA-m959-cc7f-wv43"
    ],
    "description": "## Summary  In versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the \"peer name\" presented during each validation. Consequently, cryptography would allow a peer named `bar.example.com` to validate against a wildcard leaf certificate for `*.example.com`, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for `bar.example.com`.  This behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.  In practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.  See CVE-2025-61727 for a similar bypass in Go's `crypto/x509`.  ## Remediation  Users should upgrade to 46.0.6 or newer.   ## Attribution  Reporter: @1seal",
    "coordinates": "cryptography:46.0.5",
    "references": [
      "https://nvd.nist.gov/vuln/detail/CVE-2026-34073",
      "https://github.com/advisories/GHSA-m959-cc7f-wv43"
    ]
  },
  {
    "name": "cryptography",
    "version": "46.0.5",
    "refs": [
      "CVE-2026-39892",
      "GHSA-p423-j2cm-9vmq"
    ],
    "description": "If a non-contiguous buffer was passed to APIs which accepted Python buffers (e.g. `Hash.update()`), this could lead to buffer overflows. For example:  ```python h = Hash(SHA256()) b.update(buf[::-1]) ```  would read past the end of the buffer on Python >3.11",
    "coordinates": "cryptography:46.0.5",
    "references": [
      "https://nvd.nist.gov/vuln/detail/CVE-2026-39892",
      "https://github.com/advisories/GHSA-p423-j2cm-9vmq"
    ]
  }
]

• GHSA-m959-cc7f-wv43 -> fixed in 46.0.6
• GHSA-p423-j2cm-9vmq -> fixed in 46.0.7