follow-through.test.js:374 races a 3 s wall-clock deadline under mocked timers, so it fails on a green PR and costs a rerun #821

What is wrong

core/test/follow-through.test.js:374 ("a message sent again is forgotten everywhere once a turn takes it up") failed on a real CI run and passed on the rerun of the same head.

• PR ci: Compatibility nightly + local Mac CI (follows #31) #35, head f027324e: Test run 39917377405 attempt 1 — ubuntu-latest · Node 24 and tests-ok red on this case, with settle (:99) reporting condition not reached; attempt 2, same head, all green.
• The PR touched plugins/social/, docs and a changelog fragment only; core/ was unchanged. Dev2 reran the case locally 5/5 green.

So it is a race, not a regression, and it costs a rerun every time it lands on a green PR.

Why it races

settle (:96-99) spins on setImmediate against a wall-clock 3 s deadline (:97). The case enables t.mock.timers.enable({ apis: ['setTimeout'] }) (:380), so any write that a setTimeout callback would flush only happens if the test calls t.mock.timers.tick(...); the file already carries flushWrites() (:104) for the same class of early read ("Writes to inflight.json land on a later tick"). On a loaded runner the wall-clock budget can therefore expire on a condition that no tick will ever satisfy, and the failure arrives as condition not reached — which names the helper, not the case.

Expected behaviour

A wait in this case is driven by the clock the test controls (or the section does not mock setTimeout while waiting), so the test cannot lose a race with the runner. A genuine failure names the condition that was not reached.

Acceptance

1. The failing case's waits no longer depend on wall-clock: every wait that needs a mocked timer advances it explicitly, or setTimeout is not mocked in that section. settle may keep a deadline as a guard, but a passing run must not rely on it.
2. Negative control: remove the clearing write the case is about, and it fails on its own assertion (the exchange a turn took up is still noted on disk), not on settle's condition not reached.
3. node --test test/follow-through.test.js 100 consecutive runs, green; plus one CI run of the file green (the package job step that runs core/ suffices).
4. No retry, no skip, no larger timeout as the fix.

Kill conditions

• Raising the 3 s budget: it hides the race and keeps the same failure on a slower runner.
• --test-retry, test.skip, or catching the assertion.
• Loosening the assertion (for example accepting either 0 or 1 noted items).
• Fixing only this case while leaving settle/flushWrites as the default way every other case waits: the next case added to this file inherits the race.

Out of scope

• The :347 case ("a message a shutdown cancelled is sent again once …"), unless the same fix covers it for free.
• The host's write timing itself: if a write can land after every tick, that is a product question and needs its own issue with evidence.
• Other suites; this issue is about this file's waits.