deployah -> doyle: a4 twohost-a ALSO RED, and its shape sharpens the observation I sent 6 min ago into something I think changes your RCA direction. Condition (1) already fired on the Phase B red, so STOP stands; this is evidence for the respin, not a new decision.

twohost-a job 102316461906, completed/FAILURE, started 02:36:42Z. ONE failing step, and it is NOT step 10:
  step 9 "Two-host ladder — role A (joiner/driver)"   FAILED
  step 10 "Two-host web serving — role A (requester)" never reached
  thread 'two_host_ladder_role_a' panicked crates\spt-daemon\tests\twohost.rs:2496:5
  "A-3 setup suspend applied an edge at B: NoEdge"
  test result: FAILED. 2 passed; 1 failed; finished in 19.95s
At a3 step 9 PASSED on both sides and step 10 passed too. At a2 step 9 passed and step 10 failed. So this
is a THIRD distinct twohost failure mode across the attempts, upstream of the web cells this time.

AND IT IS NOT A TIMEOUT. 19.95 s, no budget named, and the log shows the ladder had already got as far as
"TWOHOST OK: toast: B's surface marks replicated back to A" — pairing worked, replication worked, then the
A-3 suspend rung asserted an edge at B and got NoEdge.

THE PATTERN SHIFT, stated plainly because it cuts against the story we have been running on: a4's TWO reds
are BOTH STATE ASSERTIONS, not budgets.
  registry_lifecycle:514  "held 0 -> 1"      an extra row where zero were required   (11.594 s)
  twohost.rs:2496         "an edge at B: NoEdge"  a MISSING edge where one was required (19.95 s)
Every earlier victim was a clock: webserve's 5 s ttl race, mesh_recovery's 600 x 25 ms converge budget,
the helper's 900 s. A bursty I/O window plausibly eats a budget. It does not obviously add a registry row
or drop an edge, and the two a4 failures point in OPPOSITE directions (extra state vs missing state), so a
single "residue on a re-run box" story does not cover them either. I am not offering a mechanism — I am
saying the contention hypothesis that justified a4 does not visibly extend to what a4 actually produced,
and todlando's falsifier ("third distinct victim = one env cause confirmed") is satisfied on the COUNT
while the CLASS moved twice. If that reads as me arguing for a product cause: I am not. I am arguing
against inheriting the env cause by default into the respin's shape, because b359e40e is a converge-budget
rider and neither a4 victim is a converge budget.

twohost-b still in_progress (started 02:36:42Z, its own budget). Run NOT terminal, so the hand-back probe
still REFUSES by its gate and I have not hand-run it.
ON THE PROBE: your split mandates it for "test GREEN + twohost RED". Here test is RED, so strictly (1)
governs and the probe is not mandated. I still think it is worth firing once the run is terminal, purely as
diagnosis: a twohost red immediately raises "did the box layers close again", and it costs 30 s to answer
with a number instead of leaving it open in the register. Say skip and I skip it; silence and I fire it at
terminal and label it diagnosis, never as d882297f's owed in-situ run.

PRESERVED: .spt/preserved/golden-272-r2-attempt4/a4-twohost-a-102316461906.log (145489 B). I will hash it
into the manifest together with twohost-b's once the pair is terminal, so the manifest is written once with
repo-root-relative paths rather than twice.