GO-2026-5932: golang.org/x/crypto reported vulnerable at module level, ignoring import scoping

Split out of #230 as suggested, since the cause and the fix are different.

Scout reports golang.org/x/crypto@0.54.0 as affected by GO-2026-5932, with an affected range of >=0 and no fixed version.
It shows up on any Go image that depends on golang.org/x/crypto.

GO-2026-5932 is a notice that the golang.org/x/crypto/openpgp package is unmaintained.
There is no fixed version and there never will be one, since the remedy is to stop importing that package. Unlike #230, this cannot be corrected by fixing the upstream data.

The Go vulnerability database scopes the record to the openpgp import paths through ecosystem_specific.imports, and govulncheck honours that scoping. Matching at module level ignores it, so every project that depends on golang.org/x/crypto for its other packages (ocsp, ssh, pkcs12, bcrypt) is reported vulnerable permanently, with no remediation.
Traefik, for instance, uses ocsp and never openpgp.

The Go team considers this a scanner-side issue:

Scanning tools that only look at module dependencies are broken by design, which is why we wrote govulncheck in the first place. Tools that are consuming Go vulnerability database records but aren't using the package/symbol information are going to surface a lot of false positives, we can't do anything about that.

golang/vulndb#5932, and golang/go#80347 which asked for the record to be narrowed was closed as not planned.

Could Scout consume ecosystem_specific.imports for Go advisories?

Start at Scout's Go advisory matching entry point and trace how ecosystem_specific.imports is handled for GO-2026-5932. Compare module-level matching with the openpgp import scope; done means projects using packages such as ocsp, ssh, pkcs12, or bcrypt without openpgp are not reported for this advisory.