feat: support --ratchet / baseline filtering in multi-folder mode

[Ayush7614]

Summary

--ratchet and baseline suppression (.cve-lite/baseline.json) work in single-folder scans but are silently ignored in multi-folder mode. Monorepos without a root lockfile — the path that auto-enters multi-folder mode — cannot adopt the documented ratcheting CI gate.

Motivation

Ratcheting docs describe --ratchet as the way to land a hard CI gate on existing debt. Multi-folder is the natural scan path for npm/yarn/pnpm workspaces without a root lockfile. Today those repos get full historical noise every run, and --ratchet is a no-op (only referenced to skip the override hint).

Related gap: multi-folder already has JSON + HTML + maintenance/--fail-on partial parity with single-folder; baseline/ratchet is the biggest remaining CI feature hole.

Proposed behaviour

1. First --ratchet run in multi-folder: write a baseline that covers all scanned subfolders (either one repo-root manifest keyed by subfolder path, or per-subfolder .cve-lite/baseline.json — open to maintainer preference).
2. Subsequent runs: suppress known findings per subfolder; only new findings (and --fail-on / override / maintenance thresholds) fail CI.
3. Exit-code policy should match single-folder: ratchet regressions + CVE/--fail-on + override + maintenance.
4. Docs: note multi-folder support in ratcheting.md and CLI reference; today --ratchet is accepted without error despite doing nothing.

Non-goals

• Multi-folder --fix / --sarif / --cdx (already explicitly rejected with a message)
• Changing single-folder baseline format unless needed for the keyed multi-folder layout

Acceptance criteria

• cve-lite /monorepo --ratchet creates a baseline and exits 0 on first run
• Second run with the same findings exits 0 (suppressed); introducing a new finding fails
• Unit/e2e coverage for save + gate paths
• Docs updated

Happy to take this if maintainers agree on the baseline shape (single keyed file vs per-subfolder).

[sonukapoor]

Thanks @Ayush7614, and good call flagging the baseline-layout question up front. Let's go per-subfolder: each scanned folder gets its own .cve-lite/baseline.json, exactly like single-folder mode.

The reasoning: it keeps a folder baselined identically whether it's scanned on its own (cve-lite packages/api --ratchet) or as part of a multi-folder run (cve-lite . --ratchet), so there's no surprise about where a folder's baseline lives. It also reuses readBaseline/writeBaseline (already parameterized by root path) as a drop-in inside the per-folder loop, so no new keyed baseline format is needed.

Concretely it should wire into multi-folder-scan.ts the same way override-hygiene and maintenance-risk already do in that loop: read the folder's baseline, save it if absent, gate against it if present, and fold the result into the exit-code decision. Plus per-folder ratchet output in the multi-folder printer and a short note in ratcheting.md / cli-reference.md.

All yours if you'd like to take it. Happy to point at the exact single-folder wiring in index.ts as a reference if that helps.

[Ayush7614]

Thanks @sonukapoor — per-subfolder makes sense, and I'll take it.

Plan: reuse readBaseline/writeBaseline inside the multi-folder loop (same as single-folder in index.ts), fold ratchet gating into the exit code with CVE/override/maintenance, add per-folder printer output, and note multi-folder support in ratcheting.md / cli-reference.md. Opening a focused PR shortly.