Wire the merge-admission producers into --required-ci, and make a green certificate over a red run unrepresentable

[gunbai-bot]

What this closes

gunbc.merge_admission already models the wall that would have refused the merge behind the 2026-08-21 main-floor red: classify_merge_admission_verdict_v2 compares the receipt's tested base tree against the current merge target tree and answers MergeDeniedStaleBase — "stale base tree — re-run CI against current main".

Nothing invoked it, because nothing minted its inputs. The module says so itself, at merge_admission_current_context_staging_note: the entry "can fetch the current merge target, read attempt-scoped TestedSubject and MergeAdmissionReceiptV2 wires, and classify them … but no production path invokes the entry and no production path mints either V2 wire."

This lands the two producers merge_admission_v2_production_wires_dissolution_trigger names, as phases inside --required-ci rather than workflow steps — the 2026-08-20 operator directive puts these "within the witnesses step and within the gunbc binary, not at a github actions job level".

• Phase 0 — capture, ahead of every other phase. The subject is what the run is about, and it must exist before anything is tested: afterwards the only remaining account of it is the receipt's own claim, and a receipt that both states and certifies its subject can restate it. This is the independence merge_admission_subject_binding_note requires ("three bindings are therefore required BEFORE any freshness question").
• Phase 7 — stamp, after the floor, carrying this run's real conclusion.

Why it is not pure wiring — the part that matters

tools.merge_admission_walk stamp_tested_floor writes conclusion: Success as a literal. That was not a defect while it ran: its safety came from an ordering law held outside it, declared by the WalkPlan — "stamp is reachable only after the whole ordinary floor and its finalization passed" — so the constant could only ever be written over a run that had in fact passed.

The floor cut deleted the WalkPlan. The constant survived; the law that made it true did not. Calling it from a new site would mint a receipt certifying Success over a red run — a fabricated plausible output (§5) aimed at the merge gate, the one consumer that must never be lied to, and undetectable downstream because a receipt is believed exactly to the extent that it is well-formed.

So the conclusion becomes an operand: stamp_tested_floor_with_conclusion takes it, and stamp_tested_floor_for_exit_code routes an exit code through the existing floor_exit_to_check_conclusion rather than re-deciding what a zero exit means. The zero-argument stamp_tested_floor is retained for the existing success-stage claim, where the constant is still true by that stage's own reachability. A green certificate over a red run stops being something a caller can produce by forgetting an ordering rule and becomes something it would have to state — the §4b climb from mitigatable toward structural.

Failure arms — none of which widen

• An absent walk-attempt identity is a reported SKIP, not a pass and not a failure. The identity derives from GITHUB_RUN_ID + GITHUB_RUN_ATTEMPT + GITHUB_JOB, so the arm is unreachable on CI; off CI there is no merge attempt and therefore no subject. This is phase 5's NoSubject shape, not phase 3's.
• Every other capture refusal — head unreadable, base tree unreadable, unparseable oid, attempt dir, write — fails the phase, classified from the producer's own typed refusal wire rather than guessed.
• No subject means no receipt, and that is fail-closed rather than a gap: the gate refuses on a missing wire ("floor-receipt wire missing"), so declining to stamp cannot admit anything.

Deliberately not in this change

gunbc.ci_failure_class merge_freshness_gating_status stays GatingComputedDeferred. Flipping it to GatingEnforced converts every in-flight branch the moment it lands and is gated on operator sign-off, so it belongs in its own change with a single subject.

Receipts

• Remote release build of claim_executor: CARGO_EXIT=0 with Finished release profile, against a must-fail control in the same dispatch (a nonexistent bin) returning 101 — so a real compiler was reached, not a cached no-op.
• gunbc compile on dag/tools/merge_admission_walk.dag: 0 source annotation diagnostics, no errors.
• The phases themselves are exercised by CI on this PR, which is the first run containing both producers.

Diff hygiene note: the first push of this branch accidentally reverted #8743 by copying a working file onto a newer origin/main. Caught from the diffstat (290 deletions for a change that adds ~126 lines), corrected by replaying only this change's own hunks onto current main, and re-verified: claim_executor.rs is now +126 / −0. The compile receipt above is from the corrected base; the earlier one was void.

[gunbai-bot]

Execution receipt from this PR's own run (32467142304) — the first run containing both producers. Green alone would not establish that they ran, so the log lines:

required-ci: phase merge-admission-capture (tested subject, before any phase)
[file] write .gunbc/merge-admission/32467142304-1-witnesses/tested-subject.wire (162 bytes)
required-ci: merge-admission-capture OK tested subject recorded
...
required-ci: phase merge-admission-stamp (receipt, conclusion from this run)
required-ci: merge-admission-stamp OK receipt minted conclusion=success
required-ci: phases_run=8 failed=0

The subject wire landed at the attempt-scoped path carrying the real run id (32467142304-1-witnesses), so the walk-attempt identity resolved from the GitHub environment rather than falling into the skip arm — capture is confirmed on the arm that matters, and phases_run moved 6 → 8.

What this receipt does NOT establish, stated rather than left to be assumed. The run was green, so conclusion=success is the value the operand would print whether or not it were actually being read. The failure arm — a red run minting conclusion=failure — is unexercised. What the change structurally guarantees is narrower than what it is motivated by: the literal is gone and the value now comes from phase_failures, so a green certificate over a red run is no longer producible by forgetting an ordering rule. But "the operand is genuinely consulted on the red arm" is currently an inspection claim, not an executed one.

The honest next-rung trigger is the first red --required-ci run after this lands, whose log should read conclusion=failure; that observation converts the claim from inspected to executed. I have not manufactured a red run to obtain it, because the only way to do so here would be to plant a failure on a merge-bound branch.

— sent from bold-pike-155