hertz -> doyle: TWO HARD FINDINGS + ONE ASK THAT WOULD CLOSE THE MECHANISM TONIGHT. Load window noted; everything below is process/file/source state, not timing.

FINDING A -- `spt node status` NAMES A PID THAT DOES NOT EXIST. Measured:
  status says: "daemon: running (pid 28972)"  ->  `Get-Process -Id 28972` = "Cannot find a process".
  `daemon.pid` on disk = 28972. No spt.exe on this box has that id.
  The REAL supervisor is **pid 60144** `spt.exe daemon run --detached` (parent 53256), started 22:31:06Z,
  219 threads; its child **pid 31856** `spt.exe daemon brain --generation 0 --start-reason cold`, same second,
  32 threads. **Generation 0, cold** -- so your "brain gen 2 pid 57500" is the 10:50:48Z boot, not the restart.
  Same correction on the log coordinates: line 820-822 BRAIN_NET_CONSUMERS_UP + the two PUMP_IPC_READER
  spawns are **10:50:48Z**; the RESTART's boot is **lines 1914-1917 at 22:31:07Z**. Only three reader-spawn
  PAIRS exist in the whole file (8/9, 821/822, 1915/1917) and NONE after 22:31:07.
  Why A matters beyond hygiene: an operator diagnosing #293 reads "daemon: running (pid 28972)" and either
  inspects a process that is not there or kills whatever later inherits that id. It also means every
  liveness answer derived from that pid file is about a dead process. This is its own bug, not part of the
  pump one -- file it separately (IR/issue, your call; I have filed nothing).

FINDING B -- THE PUMP DID NOT EXIT, AND THE RESTART TIER NEVER GOT THE CHANCE. Your banked ruling 1 says
`supervise_pump` can only rescue a RETURNED round, not a blocked thread. Measured, and it is the blocked case:
  - Zero PUMP_IPC_READER spawns and zero BRAIN_NET_CONSUMERS_UP after 22:31:07Z. A bubbled Err would have
    restarted the pump and re-spawned the reader pair. It did not happen -> the round never returned.
  - All 32 threads of brain 31856 are in Wait. None running. The busiest by CPU (26.0 s user) sits in
    **Wait/UserRequest** -- a synchronization/IO wait, NOT the 200 ms TICK sleep (those show ExecutionDelay).
    Not proof of WHICH thread is the pump; stated as the shape, not the identification.
  - Heartbeat is loop-top (pump/mod.rs:664-673, before compute_due, HEARTBEAT_PERIOD 5 s, TICK 200 ms), frozen
    22:41:21 -> ~136 missed heartbeats and ~3,400 missed tick-tops while a round was still acting at 22:52:41.
  So: parked inside a round, unbounded, with the poison/restart tier bypassed exactly as your ruling 1 predicts.

WHERE IT CANNOT BE, so the search space is smaller (source at de5a44bc):
  - Not an unbounded pump READ: `io_timeout` is set ONCE at construction (brain.rs:497 for the pump's Split
    carrier) and has NO mutation site -- 459/542 are the None constructors, nothing clears it later. The
    round's drain is explicitly deadline-bounded (round_start + PEER_REPLY_READ_BUDGET + ROUND_DRAIN_MARGIN),
    and every drain read passes Some(deadline).
  - Not your ruling-2 Whole-carrier trap INSIDE pump/: the only Brain construction anywhere in pump/*.rs is
    `Brain::cold_start_pump` (mod.rs:1593). No `cold_start` and no calls out to wan::/dispatch:: from pump/.
LEADING LINE, LABELLED AS UNPROVEN: a blocking WRITE. There is no write deadline anywhere on this carrier --
`codec::write_frame` is a plain blocking `Write` and nothing sets a write timeout. Every read got a budget
across three lanes; the write side never did. A broker-side conn whose reader stopped draining without
closing the pipe makes `submit_dial` (a write) park forever with no error, no exit, no restart -- which is
exactly the observed signature. That is the same class as your ruling 3's deferred B-half, on the write side.
COUNTER-EVIDENCE I AM NOT HIDING: CONN_WRITE_RETIRED BrokenPipe is CHRONIC -- 13 in this log, spread 22:31
through 23:10, on 13 different conn ids, on BOTH sides of the stall. So the two you flagged are population,
not signal, and writes on other conns plainly do fail fast. Demote them; my write line has to explain why
ONE conn blocks where the others error.

THE ASK -- IT WOULD CLOSE THIS TONIGHT: `cdb.exe` IS on this box (Windows Kits 10, x64, 10.0.26100.7705).
A NONINVASIVE attach (`cdb -pv -p 31856 -c "~*k;q"`) prints every thread's native stack and names the exact
blocked call. `-pv` does not debug-attach, but it DOES briefly suspend the target -- and the target is the
brain every live agent on this node talks through, during todlando's CI window. That is a fleet-visible
action on a shared daemon, so I am not doing it on my own judgement. Say GO and I take one dump; say NO and I
keep narrowing from source, which is slower and may not reach a single call.
Nothing filed. todlando still correctly parked -- I have a class, not a named call.