feat: make --fix / self-fix respect the configured release cooldown (hold back cooldown-window versions)

Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only. Touches the fix resolver / remediation behavior, which is kept in-house.

Summary

The cooldown-aware fix resolver (#871, #872) surfaces an advisory warning when a recommended fix version is newer than the project's configured release cooldown (npm min-release-age, pnpm minimumReleaseAge, yarn npmMinimalAgeGate). But it is advisory only: --fix (and the self-fix.yml auto-PR Action) still applies that version regardless.

That means auto-fix can adopt a just-published version - exactly the danger window a cooldown exists to avoid (a hijacked release that is live but not yet caught, e.g. the chalk/debug compromise). This issue makes fix mode cooldown-aware in behavior, not just in the warning.

Proposed behavior

• When the recommended fix version for a finding falls inside the configured cooldown window, --fix should hold it back (not auto-apply it) and clearly report why - reusing the existing cooldown message. The finding stays unfixed so the developer can validate and decide.
• self-fix.yml (the auto-PR Action) needs no workflow change - it inherits the CLI behavior, so its batched PR simply will not include cooldown-window bumps.
• Covers npm/pnpm/yarn (the PMs the cooldown reader supports); Bun is not covered.

Open design questions

1. Only-fix-is-fresh case: if the only known non-vulnerable version is inside the window, do we (a) hold it back and report "held by cooldown, validate manually" (recommended - matches the intent), or (b) apply it with a prominent warning? Lean (a).
2. Opt-out: should there be an override (e.g. --ignore-cooldown flag / Action input) for teams that want auto-fix to proceed regardless? Decide during implementation.
3. Reporting: distinguish "held back by cooldown" from "no fix available" in the fix summary and exit reporting so it is not mistaken for an unfixable finding.

Related

Builds on the cooldown-aware fix resolver (#871, #872).

Start with the fix resolver and the cooldown-aware behavior described in issues #871 and #872, then inspect how --fix and self-fix.yml consume recommended versions. Done means cooldown-window versions are held back with the existing cooldown explanation, and reporting distinguishes them from findings with no fix available.