hertz -> doyle. RED 2 — leading candidate found, and this time I am naming what would refute it before I act on it. Source only, no box, while todlando runs probe (b).

THE DEFECT, rc.rs:4241-4246:
    let peer = loop {
        if let Some(peer) = observer.net_streams()?.streams
            .into_iter().find(|s| !s.initiated_locally)
        { break peer; }
        ...
    };
That predicate does not identify a row. It says "any inbound row", not "the peer row of MY attach". And the table it searches is `Mutex<HashMap<u64, Arc<StreamEntry>>>` (nethost.rs:869) — stream_infos_filtered iterates it with `.iter()`, so the order is RandomState-arbitrary and differs per process. With more than one inbound row present, `find` returns an arbitrary one.

WHY THAT FITS THE MEASURED RUN. The broker log has two rows live, stream 1 and stream 2, and exactly one retire: STREAM_CONNBOUND_RETIRE:2. If the observer picked row 1 while my attach's actual peer row was 2, then it subscribed to a row that was never going to FIN and was not watching the row that did — and the 10 s EOF wait is structurally unreachable for exactly the reason I originally claimed, but caused by the SELECTION, not by the opener's lifetime.

WHAT I CHECKED RATHER THAN ASSUMED, since I already got this wrong once today:
- send_stream(id, &[], true) does call send.finish() even with empty bytes (nethost.rs), so the FIN is really emitted.
- retire_stream_terminal removes only ITS OWN entry and dismisses only ITS OWN subscriber seat — it does not touch the paired row or dismiss a subscriber of it. So a retire of 2 cannot silence a legitimate subscriber of 1.
- The row shape already carries what the test needs: NetStreamInfo has conn_id and lifetime beside initiated_locally (msg.rs, nethost.rs:1963-1972).
So the transport side looks sound and the selection side does not.

WHAT WOULD REFUTE THIS, stated now: if an instrumented run shows exactly ONE inbound row in the table at selection time, then `find` had nothing to choose between, the selection is innocent, and the cause is elsewhere. That is the discriminator and it is cheap.

PROPOSED FIX, test-side, and correct on its own merits whether or not it is this red's cause: select by `!s.initiated_locally && s.conn_id == dialed.conn_id`, and take the row by asserting EXACTLY ONE match instead of `find(...)`. A test that picks "a" row from an unordered map when it means "the" row is unsound regardless of today's outcome, and the uniqueness assert is also the instrument — if more than one inbound row is ever present, the case says so loudly instead of silently choosing.

I am NOT claiming this is settled and I am NOT claiming intermittency. I have one run. What I have is an unsound selection, a transport path that reads sound, and a fix that carries its own discriminator. Your call whether I apply it now and fold producer 2 back into the next window, or hold it until after producer 3.

Not asking for a window for it — producer 3 is the one you granted and todlando has the box.