hertz 06:2xZ — served-URL census done. Headline: the hazard is real, and it does NOT intersect my sweep. ZERO of the 31 rigs I flagged mint or fetch a served URL, so the flag sweep moves listeners belonging to rigs that never ask for a URL. Nothing of mine got worse; nothing of mine needs pinning.

CENSUS over all crates/*/tests (serve as a CLI arg, docs url, an HTTP request, /f/ or /m/, SPT_DOCS_PORT, a bound-port read). Rigs with genuine URL traffic: THREE, and all three already take the port from the real listener, so 0 pinned, 0 left talking to 5474:
- spt/webserve_cross_node_e2e — reads it off the daemon's own DOCS_SERVER_UP line (docs_port(), :157; its own header says "the rig asks each daemon what it is"). This is the only rig that carries the flag AND does URL traffic, and it is safe by construction.
- spt-daemon/webserve_e2e — start_serving(..., 0), uses the RETURNED port.
- spt-daemon/twohost_web — the rig's own explicit port pair + PORT_OFFSET.
Two false positives, named so nobody re-derives them: oneliner_e2e's "curl" is a comment about which shell the curl-pipe target is; servicehost_supervision_e2e's "serve" is a service NAMED serve.

CORRECTION, and it matters for todlando's f1-attach fix: pinning ONE SPT_DOCS_PORT while the flag stays set does NOT make URL and listener one number. The flag WINS — resolve_daemon_docs_port returns 0 BEFORE the env override is read (docshost.rs). That is IR-78, and it is your own measurement: you set SPT_DOCS_PORT=5480 and got DOCS_SERVER_UP on 55369 and 44015. A rig pinned to 5493 under the flag would mint 5493 and listen somewhere else — it would stop hitting the fleet, so his 404 would go away, but it would then be fetching a port nothing is on, and the rig would be green-by-accident only if nothing asserts on the fetch.

Two shapes actually work for a URL-minting rig: (a) DROP the flag and pin a non-5474 port, so listener and URL are both 5493; or (b) read the bound port. All three rigs above already do (b), which is also the shape releases#282's product fix should generalize — the URL must come from the bound port, and then no rig needs a pin at all.

PR body updated with the census, the count in your form (31 touched / 0 with URL traffic; 3 with URL traffic / 0 needing a pin / 0 left on 5474), releases#282 cited on the defect sentence, and the correction above. Still HOLDING for your clear; box is still todlando's.