feat: detect stale override floors that no longer change the resolved version (OA009)

[sonukapoor]

Problem

Teams add >= override floors to clear CVEs - for example "js-yaml": ">=4.2.0". Over time the ecosystem catches up: upstream fixes ship, the package gets dropped from the graph, or the un-overridden resolution already satisfies the floor. But package.json never records why an override was added, and nobody removes a security pin blindly. Stale floors accumulate.

Why the existing rules miss this:

• OA001 catches orphaned targets (package gone from the graph entirely)
• OA004 catches surpassed concrete pins - but skips ranges entirely

A >= floor where the un-overridden resolution already meets it is detected by nothing. It looks like an active security control and functions as dead weight.

Proposed solution

OA009 detector

A new rule that flags a >= or ^ override floor as stale when:

1. The package is still present in the resolved graph (not OA001)
2. The un-overridden resolution already satisfies the floor constraint
3. A re-resolve verify confirms removal changes nothing

Severity: low (safe to remove, no CVE risk)
Auto-fix: yes - remove the entry, or downgrade to a comment-only record

overrides.json provenance ledger (optional companion)

A committed file (overrides.json) that records the provenance of each override entry:

{
  "js-yaml": {
    "floor": ">=4.2.0",
    "advisory": "GHSA-xxxx-xxxx-xxxx",
    "added": "2023-04-12",
    "addedBy": "sonu@example.com",
    "reason": "CVE-2023-XXXXX in js-yaml <4.2.0"
  }
}

cve-lite overrides reads this file when present and includes provenance in findings output. OA009 uses the advisory field to backstop the re-resolve check - if the advisory is still open, the floor is not stale regardless of the resolved version.

Acceptance criteria

• OA009 fires when >= floor is redundant; does not fire when the floor is still load-bearing
• --fix removes stale floors safely
• overrides.json is read when present; absence is not an error
• Integrates cleanly with existing OA001-OA008 output format

Related

Part of the dependency hygiene engine - see umbrella issue #733