feat(storage): merge gate request kinds and an apply-in-flight check hold

[aparajon]

Why this matters

When an apply starts changing a target schema, every other open PR holding a green check against that same (environment, database type, database) target is now holding a verdict that may no longer be true — and nothing stops a merge from landing on it while the apply is still running. The existing merge gate guardrail only reacts after an apply completes. Closing the window before and during an apply requires two new durable primitives, which this PR adds at the storage layer. Stack 4/7, on top of #866.

What it does

• Adds a kind column to merge_gate_requests, splitting the outbox into two request kinds:
  • settle — the existing post-terminal re-plan of sibling PR checks (all existing rows and writers).
  • preflight — a new request recorded before an apply's engine work starts, consumed by holding sibling PR checks action-required.
• The unique key becomes (apply_id, kind) so one apply can carry both requests through its lifecycle.
• New store operations the follow-up PRs consume:
  • ReopenForRetry — re-arms a terminally failed request so a gate can retry it.
  • FindTerminalAppliesWithPreflightMissingSettle — finds applies whose preflight held sibling checks but whose settle (the release) was never recorded.
  • HasActivePreflightedApplyOnTarget — detects a live hold on a target so a settle doesn't prematurely release it.
  • MarkBlockedForApplyInFlight — conditionally flips a stored check to blocked, refusing to touch rows owned by an in-progress apply or a moved head SHA (optimistic concurrency on the head SHA).

                     merge_gate_requests
 apply lifecycle      (apply_id, kind) UNIQUE
 ───────────────      ──────────────────────
 before engine   ──►  kind=preflight   hold sibling PR checks
 work starts                           (consumed in follow-up PRs)
      │
 terminal state  ──►  kind=settle      re-plan sibling PR checks,
                                       releasing the holds

How it moves us toward the northstar

Merging a PR should be safe exactly when its checks are green. This stack makes an in-flight apply on the same target visible in every sibling PR's checks, so git remains the interface and the check state is never a stale rendering of reality. This PR is pure storage; the processor fan-out and the operator gate build on it.

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