feat(github): hold sibling PR checks and comment when an apply preflights a target

[aparajon]

Why this matters

A green check on a sibling PR is a promise that its plan still matches the target schema. The moment an apply starts changing that schema, the promise is stale — but today nothing on the PR says so, and the merge gate processor only knows how to re-plan after the apply finishes. This PR teaches the processor to consume preflight requests: hold every sibling PR's check action-required and explain why with a PR comment, before the apply's engine work begins. Stack 5/7, on top of #939.

What it does

• Preflight fan-out (fanOutCheckPreflight): for each open sibling PR with stored check state on the apply's target, conditionally flips the stored check to blocked (apply_in_flight_on_target), updates the aggregate Check Run, and posts one explanatory PR comment. Checks owned by an in-progress apply and closed PRs are skipped with logged outcomes. The flip is optimistic on the head SHA, so a PR that moves mid-fan-out is never stomped.
• Hold comment (RenderCheckHold): tells the PR's author what is changing, on which target, by whom, and what to do next (wait for the apply to settle; checks re-plan automatically). Idempotent via a hidden per-apply marker, so webhook redeliveries and retries never double-post.
• Settle deferral: a settle fan-out completes without re-planning while a later preflighted apply is still active on the same target — the re-plan would mint fresh green checks against a schema mid-change.
• Release sweep (sweepPreflightedAppliesMissingSettle): settles are now the release valve for holds, so any apply that reaches a terminal state with a preflight but no settle (e.g. cancelled while queued, where no drive tail runs) gets a settle backfilled. A hold can never outlive its apply.
• Consumer registration moves from handler construction to StartMergeGateProcessor: a registered consumer now means "a processor is running and will drain requests", which the operator gate in the follow-up PR relies on.

 preflight request ──► hold sibling checks ──► PR comment (once)
                        │ skip: in-progress apply-owned, closed PR,
                        │       moved head SHA
 settle request    ──► later preflighted apply active on target?
                        ├─ yes: complete without re-plan (defer)
                        └─ no:  re-plan siblings, releasing holds
 release sweep     ──► terminal apply w/ preflight, no settle
                        └─ backfill settle (holds never leak)

How it moves us toward the northstar

The PR's checks become an honest, live rendering of the target's state: "an apply is changing this schema right now" is visible where merges are decided, not buried in an operator log. The final PR in the stack turns this into a hard gate on apply start.

The chain: #867 (storage) → #868 (drive-tail recording) → #866 (settle re-plan processor) → #939 (request kinds + hold storage) → #940 (preflight hold fan-out) → #941 (apply-start gate) → #942 (plan-time holds). Merges bottom-up; each PR retargets to main as its base merges.

🤖 Generated with Claude Code