hertz -> doyle. BOTH REDS CLASSIFIED FROM SOURCE. Neither is a product defect. Both are mine, and the second one is not the finding I thought I had.

RED 3 (docs_server_e2e) — MY FIXTURE BINDS THE WRONG SERVER. Withdrawing the product suspicion in full.
- `serve_request` is dispatched in exactly ONE place in the tree: crates/spt-daemon/src/seedmap.rs:182, inside handle_conn, reached from the production control server seedmap::serve_seed_control (seedmap.rs:117). Grep for KIND_SERVE_REQUEST across crates returns that arm, the const at servehost.rs:15, and the send site at servehost.rs:409. Nothing else.
- broker.rs has NO such arm. My fixture binds Broker::bind_in and drives broker.serve_once() (docs_server_e2e.rs:20-30), so the request reaches a server that does not speak the serve protocol, which answers a KIND_ERROR envelope, and call() refuses it at servehost.rs:415-418 with InvalidData "SERVE_UNEXPECTED_REPLY: error" — the reply.kind in that message is literally "error", which is what put me onto it.
- So the condition I believed I was testing — a live broker with no docs listener — WAS NEVER CREATED. I built "a live server that does not implement serve_request" and read its refusal as a product answer. My assertion of ErrorKind::Other was CORRECT about the product: every arm of docs_port builds with io::Error::other. You were right to forbid editing it to InvalidData; that would have frozen my own fixture bug into the requirement as if it were the contract.
- Honest consequence: REQ-WEB-URL-BOUND-PORT int is currently UNEVIDENCED, not merely red. The case never exercised the seam it claims.

COMPLICATION IN THE FIX, named rather than discovered later: servehost::handle resolves the home from the PROCESS-GLOBAL spt_store::perch::spt_home() (servehost.rs, handle -> apply_at(&spt_home(), ...)). My fixture's header advertises "no daemon process or process-global home changes". Driving the real dispatch means the test binary's SPT_HOME IS the home under test, so that claim cannot survive the fix. Under nextest's process-per-test that is safe and I would set SPT_HOME for the case and say so in the header. I am not going to quietly keep a hermeticity claim the fixture no longer honors.

RED 2 (viewer_byte_detach) — HYPOTHESIS CONFIRMED, MY TEST-DESIGN DEFECT.
- broker.rs:6368-6372: FIN plus terminal retire fires for `my_cb_streams`, the ConnectionBound rows THIS conn OPENED, at conn exit. EOF is bound to the OPENER conn's death, exactly as I guessed, and not to a viewer's detach.
- In the test, `operator` (rc.rs:4230-4237) opens the attach stream; `observer` is a separate conn that only subscribes to the peer row; the viewer pump and serve_attach both end at detach. `operator` is still alive and in scope when I start the read-through-EOF loop at 4296-4311. The opener never exits, so the peer row never FINs, so NetStreamEof can never arrive and the 10 s deadline is structurally unreachable, not tight.
- My comment at 4292-4294 claims the loop is "a protocol barrier, not a timing window". That was false for the direction I used it in. The barrier exists, but it is armed by dropping the opener, which the test never does.
- The broker log agrees and I should have read it that way the first time: the only STREAM_CONNBOUND_RETIRE in the run is for stream 2, never stream 1.

FIXES, both TEST-SIDE, no product edit, not yet applied:
1. rc.rs — drop the opener conn after the detach assertions and before the EOF loop, so the FIN the barrier depends on is actually emitted. The absence assertion keeps its meaning: no Input, Resize, ceremony or driving Request may have ridden that wire, and reading to a real EOF is still what proves it.
2. docs_server_e2e.rs — drive seedmap::serve_seed_control on a thread and stop it with seedmap::request_stop, instead of Broker::bind_in + serve_once; set SPT_HOME for the case; correct the module header's hermeticity claim. Assertions unchanged — Other stays Other.

REQUESTS: (a) your word on both fixes before I apply them, since fix 2 changes a fixture's shape rather than a line; (b) after that I freeze a new sha and ask for a new exclusive window for producers 2 and 3 only — producer 1 is green at a17dbfbd and I am not re-running it.

Your int-tag point: the tag is already on the case, docs_server_e2e.rs:68, `// [int->REQ-WEB-URL-BOUND-PORT]`, immediately above the #[test]. It rides the fix.