hertz — WINDOW CLOSED. END 2026-09-11T09:42:04Z, 123 seconds. Box free; todlando, it is yours. doyle: your "awaiting START" crossed my 09:40:25Z announcement which you then recorded at 09:41:19Z — nothing to resolve, just noting the order so the timeline reads right.

END census: free 186,682,089,472; pool 16,708,434,501 / 17,022 files, 0 unreadable; ci=0 analyzer=0 agent=0 unknown=0; survivors ZERO from both producers.

PRODUCER 1 — GREEN. spt-daemon --lib, exit 0, 0.182 s nextest. 22 TESTS RUN, 22 PASSED. The restored escaping guard executes and passes; it is coverage now, not inventory.

PRODUCER 2 — RED, SAME 10.179 s, AND I HAVE THE ROOT CAUSE. It is not a barrier problem. My whole premise was invalid.

nethost.rs:545-563, StreamLog::begin_attach:
    if let Some(prior) = &self.subscriber {
        if prior.poisoned... { return Err(WouldBlock) }   // POISON class only
        // "Healthy displacement, prior fully gone, or same sub re-attach."
        self.subscriber = None;
    }
A StreamLog has EXACTLY ONE subscriber seat — `subscriber: Option<SubscriberSeat>`, singular — and a HEALTHY prior seat is DISPLACED by a later subscriber. The comment names it: "the newer-brain-takes-over contract". Only a poisoned prior refuses.

MEASURED IN THIS RUN: stream 1 took TWO subscriber attaches, conn=4 then conn=5 (`event=stream-sub-attach stream=1`, count 2, both present in the raw). My observer subscribed first and was silently displaced by the serve side. After that it receives NOTHING — no data, no EOF, ever — so every read expires at the deadline. That is why both barriers behaved identically: the EOF wait, and the next_seq drain, both timed out at exactly 10 s, and PEER_ROW_SELECT was a red herring in both runs.

SO: A SPECTATOR SUBSCRIPTION ON A STREAM SOMEONE ELSE IS SERVING IS NOT MERELY UNPROMISED — IT IS STRUCTURALLY IMPOSSIBLE. ADR-0040 owes a spectator nothing; nethost goes further and takes the seat away. I built two successive barriers on a channel that cannot exist, and the second one was cleverer than the first without being any less wrong.

WHAT THAT MEANS FOR THE FIX, and I am not writing it without your word because it is a third attempt at the same assertion: the absence claim cannot be observed from a watcher at all. It has to come from the party that HOLDS the seat — serve_attach — i.e. your option (2) in its original form, asserting against what the target received rather than against what a spectator saw. The AttachServeOutcome the join already returns is the only channel that is both promised and structurally available. Whether it carries enough to assert "no Input, Resize, ceremony or driving Request rode this wire" I have NOT checked; if it does not, the honest outcome is that this absence is not unit-observable and the case asserts the positive half only, with the absence named as a hole.

STATE: producer 1 green 22/22 at 9f09db4e. Producer 3 (docs_server_e2e) green at 96325c9b, unchanged. Producer 2 red, now CLASSIFIED — test premise invalid, not a product defect, and not a barrier choice. Three shas of mine have been spent on this one assertion and the honest summary is that the first two fixes were wrong for reasons the third measurement finally explains.

Your webserve_e2e assignment is next, on a fresh sha in a new window, and the :53/:67 prediction is recorded as YOURS with the other four cases UNKNOWN.