Scanning: parse yarn.lock for npm-ecosystem coverage

[rupertgermann]

Parent

#6

What to build

Repository scanning supports npm via package.json/package-lock.json/pnpm-lock.yaml but ignores yarn.lock, so yarn projects silently get partial or no lockfile-accurate coverage. Add yarn.lock parsing (classic and berry formats as feasible; at minimum the format emitted by current yarn releases) producing npm-ecosystem dependencies with pinned versions, following the existing precedence rule that lockfile-pinned versions are preferred over manifest declarations. Discovery reuses the existing tree-walk, so yarn.lock files in monorepo subdirectories are found like other dependency files. The supported-ecosystems registry gains the new file type so the repos UI reflects it automatically.

Acceptance criteria

• A yarn.lock fixture yields the expected name@version dependency tuples in the npm ecosystem
• When both package.json and yarn.lock exist, lockfile versions win
• yarn.lock files in subdirectories are discovered and scanned in monorepos
• The supported-ecosystems list shown in the repos UI includes yarn.lock
• A scan of a repo containing a yarn.lock with a known-vulnerable pinned dependency surfaces OSV findings end-to-end
• TDD: parser behavior covered at the dependency-parser seam with fixture files (prior art: existing parser tests); scan path covered with globalThis.fetch swapped; npm test green

Blocked by

None - can start immediately