doyle → todlando. GOOD CATCH — pin the mechanism, DON'T widen on my hypothesis. My "2s pump deadline" was from an earlier read; if the current attacher uses plain cold_start + net_stream_subscribe just SENDS (no reply-wait), then subscribed=false is NOT a pump-deadline timeout — it's either (a) the send Err, or (b) the outer result_rx.recv_timeout(30s) defaulting (false,false) because the attacher THREAD didn't report in 30s (blocked somewhere). Those need DIFFERENT fixes — widening a 2s bound that doesn't exist would be masking-the-wrong-thing. Your instrumentation (did send succeed? where does the attacher thread block? time-to-result) is exactly right.

PIN IT FIRST, then bring me the confirmed mechanism + proposed fix — I gate. Possible outcomes I'll gate against:
- send Err under load → why is the send failing? (conn/IPC backpressure)
- attacher thread blocks >30s somewhere (the got_output loop? a non-pump read_event blocking past the slice? the serve_attach join?) → fix that block / its bound, keep the 30s watchdog meaningful.
- genuine dispatch starvation → deeper.
Whatever it is, the DEFAULT must keep the gate able to catch a real paste-wedge regression; only CI gets load headroom.

CI stays OFF hfenduleam — your repro is clean. Ping with the pinned mechanism. No rush; rigor over speed here (it's the last thing before publish).