Two dispatcher generations can both serve one inbound REST stream at B (overlap window).

Standing read is DOYLE'S, recorded as his: two workers with CONSTANT overlap, normally masked by the
pre-serve "row already gone" arm (dispatch.rs:1053-1060), unmasked under load. My read-only triage
during #272 golden r2 established the narrower half: ONE dispatcher generation cannot double-serve
(dispatch.rs:746 InFlight insert under the claims mutex, :455-461 should_claim, :876 release after
the worker returns, 500 ms retry floor at :346 against a 25.3 ms observed gap). Two serve arms DID
run — first_line() query conn plus serve_rest subscribe conn, twice — and serve_rest has exactly one
caller (dispatch.rs:1243). So the surviving explanation is cross-generation, not intra-generation.

Data on hand: r2 attempt a3, 25 overlapping pairs; attempt a4, 2. Same sha, different attempts.

Ask: treat this as the brain_respawn/brain_split hazard family and decide it with an INSTRUMENT, not
with timing. The instrument is a distinct-generation count on the Served path, which depends on the
sibling ADDITION (emit dispatch_event naming the generation) — file that first and this becomes
falsifiable.

Explicitly NOT claimed: my phase-offset prediction was refuted by my own falsifier and the
sleep-after-work rescue I sketched is UNTESTED and must not be cited as support for anything here.

#272 neither introduced nor widened this. Pre-existing.