todlando — PROBE EXECUTION END 2026-09-11T09:15:0xZ. hertz: box is yours, open producer 3. doyle: classification below, and it is NOT the one probe (b) alone pointed at.

THREE PROBES, one attempt each, admission sampled before each (09:12:57Z FREE=192,645,558,272 / 09:13:43Z FREE=192,642,662,400), builders 0 and test binaries 0 at every sample.
(a) local_attach_via_loopback_conn_rides_the_same_pump, UNMODIFIED — GREEN, 1 passed, 0.116s, exit 0.
(b) my cell, N-1 control arm FIRST — arm n-1-control PASSED (ARM_DONE policies=-1, the N-1 contract answered end to end), arm stale-windows-controller FAILED: "[stale-windows-controller] operator broker error: no such stream 2". Both arms opened on viewport_stream=2 serve_stream=1 conn=1 — identical topology.
(c) THE PROBE I ADDED AFTER (b) AND BEFORE CONCLUDING ANYTHING: the same identity-free control arm duplicated so it runs in POSITION 2 as well. Result: "[n-1-control-second-position] operator broker error: no such stream 2".

(c) REFUTES WHAT (b) LOOKED LIKE. After (b) the tempting read was "the arm that declared an identity failed, in both runs, in both positions — identity is the invariant". It is wrong. An arm with NO client identity fails identically when it runs second. Declared identity is NOT necessary for the failure, so my ClientPolicy push is not what produces it, and I would have shipped a product accusation against my own change if I had stopped at (b) and let the two runs agree with each other.

CLASSIFICATION: outcome 2 in the prediction file — TEST-SIDE, MINE. The mechanism my own trace supports: each arm's helper creates its own operator, and returning from an arm drops it; that conn's exit FINs and terminal-retires the ConnectionBound rows it opened (hertz's source-verified broker.rs:6368-6372), while the broker recycles the same stream id into the NEXT arm's viewport. ARM_OPEN prints it plainly — arm 1 and arm 2 both get viewport_stream=2 on conn=1, and STREAM_CONNBOUND_RETIRE:2 lands between them. The next read then correctly finds no such stream. The product is behaving as designed; my helper is what re-uses a just-retired id.
WHAT I AM NOT CLAIMING: that a terminal retire keyed by stream id without a generation is safe in general. It is a candidate hazard and it is NOT what my evidence establishes, so it goes to you as a question, not a finding.
STILL UNEXPLAINED AND SAID OUT LOUD: in the FIRST run the failing arm was in position 1 with no prior arm to retire anything. Either that arm's id was recycled from the session spawn's own conn, or there is a second path to the same symptom. My fix has to hold for that case too, or I have only moved the red.

FIX I AM ABOUT TO WRITE (not yet applied): one operator Brain created once in the test body and borrowed by every arm, so no conn exits between arms and no id is recycled under a live viewport. That is the shape the existing passing helper already has — attach_drive_detach takes operator: &mut Brain from its caller — which is also why (a) never saw this.
REQ-ATTACH-CLIENT-STALE int stays MEASURED RED until that fix runs green in a slot you grant; doc/impl/unit unchanged and green. Instrumentation still uncommitted per your ruling. Evidence: run-probe-{a,b,c}.{stdout,stderr} and probe-prediction.txt under .spt/preserved/remote-friction-304/todlando-product-build/.