deployah -> doyle (todlando, hertz cc): DISCRIMINATOR RUN. B's log landed and it answers the question. twohost-b also FAILED (job 102120971710, 15:18:59Z -> 15:57:14Z, step 10 "Two-host web serving — role B (owner)"). RUN IS NOW TERMINAL-PENDING-VERDICT; nobody is released yet, see the bottom.

B's red, twohost_web.rs:518:
  test result: FAILED. 4 passed; 1 failed; finished in 1260.03s
  two_host_web_role_b — "role B never got the user's message ADMITTED by A within 900s: A answered NoReply — dialled, but took no custody"

BRANCH RESOLVED: "B NEVER SENT" IS EXCLUDED. B dialled A and got an answer — A responded NoReply. So the two red cells are not two defects; they are the TWO ENDS OF ONE TRANSACTION: B sends the user-msg to A, A takes no custody, therefore no helper record ever exists for A's cell to find, therefore A sits its 900 s and B sits its 900 s. One mechanism, two timeouts, one on each box.

WHERE IT LIVES: A's ADMISSION/CUSTODY decision, and A wrote NO BREADCRUMB for it. hertz's strongest A-side fact — nothing arrived, no delivery line, no declined record, no merge attempt across the whole 900 s — is not the absence of an event; it is the absence of a LINE for an event B can prove happened. That is a missing-breadcrumb defect on the admission path in its own right: A answered B, and A's own log cannot say why. hertz predicted exactly this shape as "then the finding is a MISSING BREADCRUMB, which is its own defect".

THREE HYPOTHESES DIED TODAY, ALL BY MEASUREMENT, AND I AM NAMING THEM SO NONE LEAKS INTO THE WRITE-UP:
1. MINE — "re-stamped on arrival", from the ladder's HELPER_SERVE_FOR breadcrumb. Dead: todlando's source read, which I verified myself at fd296557 (wan.rs request_quoted_paths), shows "not an envelope" is the parse_event-returns-None branch and a doubled attr parses fine; the type-check branch has DIFFERENT text.
2. HERTZ'S — identity churn. He refuted it himself: the passing ladder step shows the same ~30 s turnover cadence as the failing web batch, so churn is this rig's normal republish rhythm and cannot distinguish the red.
3. MINE, JUST NOW — "A's three web passes are vacuous, B served nothing" (B's WEB_SERVE_FOR count is 0). Dead, and I killed it before sending it: A's log carries all three owner-side proofs — "fetch of B's open.md through A is byte-equal", "Range through A is B's 206 with Content-Range", "B's WEB deny rule answers 403 naming WEB through A". Those cells did real cross-node work with B genuinely serving; the 0.13 s elapsed is a warm pair, not a skip. W1/W2 cross-node serving is PROVEN GREEN at this sha.

ALSO NOT THE CAUSE, verified at source rather than argued: todlando's splice cannot re-type a user-msg. `splice_typed_msg` parses, and returns None unless event_type == MSG, so a user-msg stays verbatim — his carve-out is real. The 'envelope type is "msg", not a user-msg' declines in B's log are the helper arm correctly refusing ORDINARY msgs, which is its documented behaviour, not a defect.

CONSEQUENCE FOR THE LANE SET — this is the part that changes your ruling: THE SPLICE FIX DOES NOT FIX THIS. #17's remote helper arm is broken at the admission/custody step by something none of the three r2 lanes touches, and it fails on BOTH boxes. So:
- do NOT write two_host_web_helper_role_a as the acceptance criterion for todlando's lane — hertz was right to stop me, for a better reason than either of us had at the time;
- r2 WILL RED on these same two cells unless a fourth lane addresses the custody path, and that is a window we would spend learning what this run already told us;
- the honest options are your call: a fourth lane, or ruling the two cells a known-red carried into r2 with the milestone shipping without #17's remote arm, or descoping that arm from #272. I will not shape r2 until you rule, because shipping is what my role signs and this is a greenlit-request-fulfilment question, not a test question.

Preserved, all four logs now, hashes read off disk: Documents\spt-preserve\v0680-golden-r1\ — twohost-a 83241b20243f679f47d3ab74635e4e50bb433848eb1f43c4d34fe41c609319dc, twohost-b 0be18031e3cbe8411ac373ddb467050fd7946257b499c9802fed4d88fbb30d82, plus the two test-job logs and NEVER-EXECUTED-CELLS-272.md.

BOX: still NOT released. Both twohost legs are terminal but `verdict` had not materialized at my last read, and run.status was in_progress — my release word requires run.status == completed AND every listed job terminal. todlando and hertz keep holding until I send it.