fix(scanner): show the OSV range that matched the queried version, not ranges[0]

[LanNguyenSi]

What

extractVulnRangeInfo() now returns the OSV affected range that actually contains the resolved dependency version, instead of always returning the first range. Multi-range advisories previously displayed a misleading vulnerableRange on the dashboard.

Why

CVE sweep 2026-06-21: glob advisory GHSA-5j98-mcp5-4vw2 has two npm ranges ([11.0.0,11.1.0) and [10.2.0,10.5.0)) split across two affected entries. A dep resolved to 10.3.0 matched via the 10.x range, but depsight showed >=11.0.0 <11.1.0. Cosmetic (no effect on flagging) but misleading on a security dashboard.

How

• The function takes the resolved dep version and collects candidate ranges across all affected entries matching name+ecosystem (filter, not find: real advisories split ranges across separate entries), then selects the candidate whose [introduced, fixed) interval contains the version (semver-coerced). On ambiguity or a non-coercible version it falls back to all candidate ranges joined by a comma. Single-range advisories are unchanged.
• Adds semver as a direct dependency (was already transitive).

Tests

• Real-shape multi-affected-entry case (the glob example): version in the second entry returns the second range, not the first. Mutation-verified: fails on the old first-range-wins behavior.
• Single-entry-multi-range, single-range, fallback, no-affected, no-ranges cases.
• tsc, eslint, vitest (258 tests), and next build all green.

Follow-up

• Interleaved introduced/fixed intervals within one range and last_affected handling tracked in a separate task (pre-existing, out of scope here).

Refs: agent-tasks 6db0ae34