UI gate as a presubmit: test the MERGE RESULT, not the PR branch nf-mb8c ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/416 by tools/beads/import_github.py's reconcile pass.

Follow-up to #389 / PR #407, filed at Aedan's request. #407 is the post-submit gate and stays as-is — his call, 2026-08-02: *"lets have it as a post-submit for now, claude is v diligent so this will catch 100% of issues in practice (just churn / noise from followup PRs)."* This issue captures the future work, it does not propose changing what just landed.

Pairs with #417 (where would CI run) — this one is the what, that one is the where.

The distinction that matters

"Presubmit" is not one thing, and #407's PR body was sloppy about it. It claims *"a PR-side gate would NOT have caught #387."* That is true of a gate on the PR branch and false of a gate on the merge result.

• Presubmit on the PR head — misses #387's entire bug class. #359's suite was green on its own branch; the regression existed only in the interaction with a main those probes were pinned to (widening the label column moved the geometry focus-cujs / grid-scroll navigate by). A branch presubmit passes and lets it through.
• Presubmit on the merge result (refs/pull/N/merge — what real CI actually tests) — *would* have caught #387, because that ref IS main+PR merged. This is the version worth building.

Residual gap: main can move between the check and the merge, so a passing merge-result check can still land a regression. Closing that needs a merge queue (test the exact sequence about to land). Probably over-engineering for this repo, but worth naming so nobody thinks merge-result presubmit is airtight.

Why post-submit is the right call *today*, on measured numbers

Not just "it's slow" — the economics genuinely favour it at this repo's shape:

• Full sweep = 3m28s (build + 24 probe launches), measured on main @ 7b581cd, 2026-08-02.
• Post-submit runs once per merge. A handful a day.
• Presubmit runs on every push to every open PR. On 2026-08-02 there were 7 open PRs iterating on review feedback — easily 20–30× the runs for the same coverage.

So presubmit is worth building for *earlier feedback*, not for cost. And #407 stays as the backstop regardless: even with merge-result presubmit, post-merge main is the only tree that is definitionally real.

What a presubmit would need

1. Somewhere to run — see #417. This is the actual blocker.
2. Trigger on refs/pull/N/merge, not the head ref.
3. Report as a GitHub status check, which is the part merge_pr.sh fundamentally cannot do. Today the gate is a *convention*: merge from the GitHub UI or set SKIP_PROBE_GATE=1 and nothing runs, and branch protection can't require a check that never reports. A presubmit is what makes it enforceable.
4. Decide what a red gate does — block the merge, or report only. Post-submit is deliberately non-fatal because the merge already happened; presubmit has a real choice to make.

The cheap intermediate nobody is doing

f5/integration is already main + every open PR merged, rebuilt several times an hour, and already runs build + tests + import — but never probes. #389 dismissed this as *"option C — wrong target, it would gate f5, which is already green."* I don't fully buy that reasoning: f5 being green is evidence, not a tautology, and a sweep there would catch cross-PR interactions before any of them land. It is close to free since the rebuild already happens.

Cheaper than CI, weaker than a status check, and it does not tell you *which* PR broke it. Possibly the best ratio available until CI exists.

Related: #389 (the gate), #407 (the post-submit implementation), #412 (its residuals), #414 (shell-tier test harness).