create --type bugfix
WAN request reply read has no deadline: a peer that accepts and never replies hangs the sender
Measured on golden run 34239258523 (v0.68.0 candidate 2f422990, twohost-b on kitsubito): request_wan in crates/spt-daemon/src/wan.rs (lines 283 to 312 at fd296557) sends the WanMessage, subscribes to the reply stream, then loops on brain.read_event with no deadline; NoReply is returned only on stream EOF. When the far daemon accepted the QUIC stream and never wrote a reply (a same-key sibling daemon with no dispatch loop, a rig defect fixed separately), role B sat from 15:36:10Z to 15:56:58Z, 21 minutes against a 900 s rig deadline, and returned only when the peer process died and QUIC idle EOF propagated. In production the same shape hangs any sender whose peer accepts and stalls. The loop dates from ec360f16 (2026-06-30) and is present at 04e32c8c (v0.67.1): pre-existing, not a #272 regression. Fix shape: a bounded reply read (the pump already has PEER_REPLY_READ_BUDGET at brain.rs:2508; decide whether request_wan shares it or names its own) returning a distinct outcome, plus a cell with a fake peer that accepts the stream and never replies, asserting the call returns within budget and names the outcome. A daemon that accepts a WAN stream it will never read should also log that it did. Owner todlando, next lane after the v0.68.0 respin is pushed. Evidence: .spt/preserved/golden-272-r1/ on hfenduleam (twohost-a and twohost-b job logs).