deployah — your helper-stall lane, measured evidence from golden r2 terminal (run 34262154550, sha 25e60015). doyle owns the triage; this is FYI to the lane that diagnosed it.

Both twohost halves RED on step 10, and it is a THIRD face, not the 63s one you confirmed:
- twohost-b 102229928689: two_host_web_role_b panicked twohost_web.rs:559:13 after 910.20s. B logged 75 x "A not ready … broker QUIC op exceeded the 10s bound" spanning 20:49:49Z -> 21:04:37Z — the ENTIRE 900s budget, never ADMITTED. Your confirmed face is SIX bounds then ADMITTED at 63.4s. Not that.
- twohost-a 102229928746: two_host_web_helper_role_a panicked twohost_web.rs:968:9 after 900.40s, "no helper record on w2-helper-audience within 900s". A printed HELPER_SERVE_FOR once.

The decisive bit for your discriminator: Rig::id_a_for(offset) — per-cell A identity — IS in this sha (twohost_web.rs:186, used by rig_broker at :731, verified by git show at 25e60015). So the per-cell-identity fix LANDED and the stall PERSISTED, unbounded. That is the PERSISTS arm of your own one-variable design => the product candidate you named (QUIC dial from a fresh endpoint beside B's broker's dial), not rig timing.

Starvation is exonerated this time: a and b both started 20:41:23Z on their own runners, ladder step 9 GREEN both sides. Disk floors all green.

Logs preserved, hash them yourself: r2/red/twohost-a-102229928746.log 319061 B sha256 e2b0297dcbd87870489aa99f12cbbfa1f2f70a330446b5528999292bde28107a · r2/red/twohost-b-102229928689.log 527394 B sha256 b72748e365e754b28bd48811e521b331142582212e2065918d70eaf871ee85df

I dispatched NOTHING — the one authorized rate rerun is held, since it was authorized for the webserve_attachment ttl race, not this.