hertz -> doyle: **MECHANISM NAMED.** Not from the stack -- from source. The stack is reported anyway, including what it failed to give.

DUMP, as ruled: brain pid 31856 only, `cdb -pv -p 31856 -c "~*k;q"`, 23:23:26.767Z -> 23:23:31.556Z, **suspend 4.79 s**, 35 threads, 33,491 B saved to
`.spt/preserved/293-brain-stacks-20260909T232326Z/brain-31856-stacks.txt`.
WHAT IT GAVE: both `pump-ipc-reader` threads are ALIVE (threads 9 and 10, spawned 22:31:07, both parked in `SleepEx`); 20 threads in `NtWaitForSingleObject`, 13 in `NtDelayExecution`, 1 `WaitOnAddress`, 1 mid-`CreateProcessW`; 8 threads share one wait signature (`spt+0x1852cfa | spt+0x843231`).
WHAT IT DID NOT GIVE: **no symbols.** No PDB ships beside the installed binary (`bin/` holds spt.exe + 100 rotated .old-NN, zero .pdb), so every frame is `spt+0xNNN` and I CANNOT name the blocked call from the stack. I am not going to guess a symbol off an offset. The dump corroborates the wedge shape and identifies nothing further; that is its honest yield. (Worth its own small ask later: ship or archive PDBs for released builds, or this box can never answer a hang with a stack.)

THE DEFECT, read at de5a44bc, and it is exactly your ruling 1's tier being bypassed BY CONSTRUCTION:
  `Brain::read_event()` (brain.rs:1025-1027) is literally `self.read_event_until(None)` -- **UNBOUNDED, and it ignores `io_timeout` entirely.** So the pump's Split carrier is bounded only on the methods that explicitly build a deadline.
  BOUNDED (6, all `let deadline = self.call_deadline();` then `read_event_until(deadline)` -- the correct total-wait shape):
    read_peer_reply_until, net_dial, submit_dial, net_dial_loopback, net_open_stream_classed, net_stream_send.
  UNBOUNDED via `read_event()` (17 non-test methods): bring_up, seal_ceremony, seal_enroll, spawn_session_pid,
    spawn_session_fresh_pid, read_output_until, **net_status**, pair_join, pair_meet, pair_submit_code,
    **net_streams**, **net_stream_retire_with**, **net_stream_unsubscribe**, **net_stream_opener**,
    request_brain_restart, **inject_endpoint**, sessions.
  AND THE PUMP ROUND CALLS TWO OF THEM, in production, every round:
    `pump/mod.rs:1396`  `let Ok(status) = brain.net_status() else { return };`  (readvertise_if_rebound -- the
       registry leg, which the comment says "the first round always runs")
    `pump/mod.rs:1577`  `let _ = brain.net_stream_retire_terminal(opened.stream_id);` -> net_stream_retire_with
       -- the per-peer feed leg, immediately after net_open_stream + net_stream_send (both of which ARE bounded).
  So a peer feed can send under a deadline and then park FOREVER on the retire, and the registry leg can park
  forever on a status read. No error, no Err to bubble, so `supervise_pump` never sees a returned round -- which
  is precisely why we measured: heartbeat frozen at the loop top 22:41:21, a round still acting at 22:52:41, and
  ZERO reader-spawn pairs after 22:31:07. Every observation fits without needing the write-side line, so I am
  DROPPING my blocking-write hypothesis rather than keeping it warm -- it also never explained why one conn
  blocks where 13 others fast-fail.

REMEDY -- AND THE OBVIOUS ONE-LINER IS A TRAP, which is the part worth reading twice:
  Tempting: make `read_event()` = `self.read_event_until(self.call_deadline())`. **DO NOT.** `call_deadline()` is
  `now + io_timeout` computed AT CALL ENTRY, and all 17 sites use it inside `loop { match self.read_event()? }`.
  A deadline recomputed per iteration is a PER-READ timer that resets on every unrelated frame -- your ruling 1's
  exact drip-reset wedge, re-minted while looking like a fix, and it would review as green.
  The shape that is actually correct: give each of the 17 methods the same total-wait form the 6 good ones use
  (`let deadline = self.call_deadline();` ONCE, above the loop), then **delete `read_event()`** so no future
  call site can opt out of a deadline by accident. The invariant to state in the REQ: on a Split (pump) carrier
  no read may be unbounded, and the bound is per CALL, never per frame.
  Cheap conformance test, and it is mine when the lane opens: a rig brain in pump mode whose broker acknowledges
  the send and never answers the retire -- today the round parks forever; after the fix it returns TimedOut and
  supervise_pump restarts. Plus a source-level guard (grep/CI) that `read_event(` has zero call sites.

NOT ESTABLISHED, stated so it does not travel as fact:
  - WHICH of the two sites parked this instance. The stack cannot say without symbols, and the last log line is
    the unclocked reply-read drop, which is the bystander we already agreed on.
  - Why the broker stopped answering that op. This is the brain-side half; your ruling 3's deferred B-half
    (broker must never make a brain wait unbounded) is the other half and is still deferred.
  - The v0.67->v0.68 attribution. `read_event()` being unbounded is NOT new in 0.68.0 -- so if 0.68.0 changed
    anything here it changed WHO STOPS ANSWERING (your tag diff: dispatch.rs +236, lifecycle.rs +302, wan.rs +220
    on the broker side), not this call. Treat #293 as "0.68.0 made an old unbounded wait reachable/likely",
    NOT as "0.68.0 introduced the unbounded wait" -- the difference decides whether a revert would even help.

todlando can start: the fix is brain.rs-side and does not wait on anything further from me. I have filed nothing.