npm lockfile: CDN-resolved SheetJS releases are reported against npm-registry ranges

## Problem

OSV-Scanner reports GHSA-4r6h-8v6p-xvw6 and GHSA-5pgg-2g8v-p4x9 for SheetJS CE 0.20.3 when an npm lockfile resolves the package directly from the official SheetJS CDN rather than the npm registry:

```json
{
"node_modules/xlsx": {
"version": "0.20.3",
"resolved": "https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz",
"integrity": "sha512-oLDq3jw7AcLqKWH2AhCpVTZl8mf6X2YReP+Neh0SJUzV/BdZYjth94tG5toiMB1PPrYtxOCfaoUCkvtuH+3AJA=="
}
}
```

The emitted OSV ranges contain only `introduced: 0`, so 0.20.3 is reported as affected. The source GHSA records carry `database_specific.last_known_affected_version_range` values of `< 0.19.3` and `< 0.20.2`, respectively.

## Primary evidence

* SheetJS advisory CVE-2023-30533 says all versions through 0.19.2 are affected and to upgrade to 0.19.3 or later: https://cdn.sheetjs.com/advisories/CVE-2023-30533
* SheetJS advisory CVE-2024-22363 says all versions through 0.20.1 are affected and to upgrade to 0.20.2 or later: https://cdn.sheetjs.com/advisories/CVE-2024-22363
* Official 0.20.3 artifact: https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz
* Independently calculated SHA-512 of that official tarball, expressed as SRI, is `sha512-oLDq3jw7AcLqKWH2AhCpVTZl8mf6X2YReP+Neh0SJUzV/BdZYjth94tG5toiMB1PPrYtxOCfaoUCkvtuH+3AJA==`.

This exact upstream-data problem was raised in google/osv.dev#4313. An OSV maintainer explained that the records are for the npm registry and that scanners “shouldn't be querying the npm ecosystem for non-npm-registry packages”: https://github.com/google/osv.dev/issues/4313#issuecomment-3494541318. A proposed GHSA fixed event was rejected because 0.20.2 was not published to npm: https://github.com/github/advisory-database/pull/6477#issuecomment-3598797590.

## Requested behavior

When parsing npm/yarn lockfiles, please distinguish a package resolved from a non-registry tarball URL from the npm-registry package before querying the npm ecosystem, or otherwise avoid classifying versions outside the source advisory's last-known-affected range as vulnerable. This is similar in principle to the source-aware work discussed in #2850, but this case uses an HTTPS tarball rather than a git commit.

I am not requesting suppression or a change to raw result counts. I am asking for source-aware matching so the scanner does not apply npm-registry-only range semantics to verified vendor-CDN bytes.

Please let me know if a smaller lockfile reproducer or scanner version/output is needed.

Start with the npm/yarn lockfile parsing and npm ecosystem query paths, using the lockfile example as a reproducer; compare this with the source-aware approach discussed in #2850. Done means a verified non-registry CDN tarball is not matched using npm-registry-only advisory ranges, while raw result counts remain unchanged.

Written by the indexing model from the issue text.