feat(merge-queue): hand a whole stack to trunk in one submission

[webjunkie]

Session 85 built the merge stack on the premise that the external queue refuses stacks outright — R4b's own comment says so, and the comment parser still maps trunk's "unable to merge this PR" to rejected. That premise expired: trunk supports GitHub's native stacked PRs and lands the rung it is given plus every rung beneath it, atomically, in one round of CI.

So the serial drain was paying N test cycles (~40 min each on posthog/posthog) plus a retarget and often a paid rebase run per rung, for work the provider does once. A four-deep stack now costs one cycle.

What decides eligibility is GitHub's signal, not ours. linkStack's branch-shaped chain still drives the UI and the serial fallback, but trunk batches only what GitHub calls a stack — so the batch path reads stack/stackEntry off the existing PR query. Nullable fields, no preview header, no extra round-trip. GITHUB_STACK_FIELDS=0 drops the selection if GitHub withdraws it mid-preview; it rides in the one query every poll of every repo runs.

The gate probe was asking the wrong branch, which turned out to be the crux. A stacked PR's own base is the rung below it — an ordinary topic branch with no ruleset and no queue — so the gate probe answered "unguarded" for every rung above the bottom one. Fixed in the queue, the auto-keep watcher, and POST /pull-requests/:id/merge, which without it merged stack members into their parent's branch.

external_covered_by (migration 0051) is the safety, not the mechanism. The provider ejects the whole batch when anything pushes to any member, so every rung below the submitted one has to be as untouchable as it is — and a covered rung has no provider comment and no gate of its own to say so.

How it decides. R4b gained a branch above the park: the submit rung falls through and submits on the stack's gate, covered rungs park hands-off, and the rungs in between still remediate — deliberately, since the provider tests them as one unit and a conflict four deep is real work that has to happen first — but never merge, arm, or submit. The submission goes to the top rung, and only when every rung is queued, ready, and visible contiguously from position 1; a hole underneath would merge a PR nobody enqueued.

A refusal is a fallback, not a wall. repoStackBatching.ts is the fourth repoMergeGate-shaped decaying tally (24h, cleared the moment a submission is accepted). A rejected on a batched stack records it and requeues for the serial drain; a rejected on an unstacked PR still blocks exactly as before.

Testing. 11 new decide cases, 4 pglite integration cases for the batch path, 22 planner/capability unit cases, 3 watcher cases. Green on all three OSes in 32m, which is the normal band for this repo.

One thing worth reading before review (second commit). The first version also woke the other rungs' groups when an entry's status changed, so a covered rung would notice its batch ending without waiting for the reconciler. That hung CI on all three OSes for 100 minutes: scheduleGroupEvaluation starts a detached walk holding a 45s withTimeout timer, so rungs scheduling each other build an endless chain of scheduled walks and the process never goes idle — vitest never exits, and the chain outlives the test that started it, so guarding on "only when the status changed" does not save it. Reverted; the 60s reconciler is the backstop, as originally designed. The cost is a covered rung reading "queued with #N" for up to a minute after its batch ends, which is latency and not correctness. There is a DO NOT comment at the call site because wanting it back is the obvious instinct.

Follow-up, noted in ROADMAP: an ejected batch dispatches its fix run at the submitted rung even when trunk's bisection blames a lower one. The run gets the stack in its prompt and has to place the fix itself.

FYI this is off a fork branch rather than a push to main — this session's credentials have no write access to Gilbert09/talyn.

https://claude.ai/code/session_01XUh4zGKpX5L9mJc32RzqBP

[webjunkie]

@Gilbert09 I found the stacks are not merged as one apparently. Let me know if this makes sense.