ci: the red-main controller cancels PR proof whose merge ref does not contain the bad commit #3321

Problem

The 2026-10-25 red-main ruling (answer 8, docs/decisions/ci-utility.md "Proof-system lane") pauses hosted proof whose merge ref contains the bad commit. The controller from #2942 is broader than that. cancelDoomed (scripts/red-main-coordinator.ts:141-155) cancels every queued or in-progress ci.yml pull_request run created after the bad commit's commit time, unless its PR is a declared fix. It never checks whether the run's merge ref contains firstBad.

As a result, a PR whose base does not contain the bad commit loses valid proof. Examples are a PR against a non-default branch that forked before firstBad, or a release branch.

Evidence

Incident #3315 opened for firstBad c14846a66. Two ready-candidate runs whose PRs target integration branches at a62db8f27, which does not contain c14846a66, were cancelled mid-run:

• run 41490484208 (CONTRACT: feat(ui-sdk): relay the Gemini Files video lifecycle for brain video watch in keyless workers #3312, base epic/1646-cost-limits at a62db8f27)
• run 41490023078 (refactor(common): hold the Claude subscription billing guard once (#2493) #3310, base epic/2539-security-helpers at a62db8f27)

Neither merge ref contained the bad commit, and both PRs then had to request confirmation again.

Acceptance criteria

• cancelDoomed cancels a run only when its tested merge ref contains open.firstBad. Equivalently, the PR's base SHA at run creation descends from firstBad. Runs whose base does not contain firstBad are left alone, and so are declared fixes.
• The same ancestry rule governs the refusal side: confirmation and heavy-feedback admission while main is red.
• A unit test covers a run on a base without firstBad (not cancelled), a run on a base that contains it (cancelled), and a declared fix (not cancelled). A mutation that drops the ancestry check makes the first case fail.
• docs/decisions/ci-utility.md and the ci: record a red main centrally, stop doomed proof and file one incident issue #2942 controller docs describe the rule as implemented, with citations updated.

Notes

Found while working the 0.45.0 epics via per-epic integration branches. Refs #2942, #3315, epic #2934.