follow-through.test.js: a mocked-clock wait burns all 20000 rounds before real I/O lands, and it kicked #1190 out of the merge queue #1192

Filed from the merge-queue failure that kicked #1190 out of the queue (Reviewer's report in #1190). Every anchor below is on main 687f805f.

What happened

The first merge_group run for #1190 — merge sha 66a6d9e5 — failed Test at core/test/follow-through.test.js:153 (a group turn cut off by a restart is picked up once, and the group is told). The PR touches only core/src/host/delivery-board.js: PR-level CI on the same tip was green, the same tree ran 18/18 three times locally, and the requeue merged as 687f805f.

The gap #1014 left

#1014 (closing #1012) gave waits that use real timers a real-clock bound: REAL_WAIT_MS = 5000 / REAL_WAIT_STEP_MS = 5 (:104-106), used in the mockedTimers === undefined branch (:110-119). The mocked branch is still bounded by rounds alone (:120-124):

• :154 the failing case calls mockTimers(t), so :157 → :148 settle(() => host.agentOf('gb').calls.length === 1) takes the mocked branch.
• :120-124 is for (i < rounds && !check()) { mockedTimers.tick(1); await setImmediate } with rounds = 20000 (:109). 20000 setImmediate turns are ~150 ms of real time — #1012 measured exactly that on the real path — while the chain being waited on does real work: inflight.json / state.json writes, the Session flush, resolving the Agent. A loaded merge_group runner can burn all 20000 before that lands.
• The comment at :107-108 is right that a wall-clock deadline must not decide a race the test controls (#821). It does not follow that the round budget needs no real-clock floor: those are different things, and the fix must go on ticking the mocked clock.

Expected

A merge_group run of a PR that does not touch this path never fails at :153; and if the ordering really can lose the relay call, that is found and fixed rather than hidden behind a bigger loop.

Acceptance

1. Measure before touching the bound, and put it in the PR body: on current main run core/test/follow-through.test.js under load (nice -n 19 plus a CPU hog) at least 100 times, and instrument the wait once to print the rounds counter at the slowest passing run (p99), for both branches. If a loaded mocked-timer run needs more than 20000 rounds, (a) is confirmed; if it never does, say so and go to (b) with the ordering you believe loses the call.
2. Fix what the measurement points at. (a) keep tick(1) every round so the mocked clock keeps advancing, and let the loop continue past rounds until a real-clock deadline (Date.now(), which mock.timers.enable({ apis: ['setTimeout'] }) does not freeze) — a floor under the existing budget, not a deadline racing it; do not put a setTimeout deadline in front of the mocked path (#821). (b) fix the pickup and pin it with a case that fails on today's code.
3. Knife, for (a): make the round budget injectable for tests only, then add one case that mocks the clock, flips its condition after a real ~100 ms write, and passes an artificially small rounds — green with the floor, red with the floor removed. Keep the added wall time under ~200 ms.
4. Test/CI only: no changelog.d/ fragment, and Docs-not-needed: in the commit message if arch-docs fires.

Not the same as

• #821 (closed): a 3 s wall-clock deadline raced a condition that only ticking a mocked delay could reach — the opposite direction from this.
• #1012 (closed by #1014): the real-timer path in the same file, fixed there; this is the mocked path it did not touch. Nothing in this issue reopens that measurement.