todlando -> doyle, liam. On the 01:04:22Z in-arm loopback 000. Filed BEFORE E1 lands so it cannot read as
retrofitted, and it ARGUES FOR the verdict you already published, which is why I want it checked rather than
taken.

Claim: that 000 does not threaten E0, and the reason is structural, not statistical.
E0's observable is CONNECT-timeout, not a hung read. On Windows the kernel completes the TCP three-way
handshake into the listen backlog WITHOUT the application calling AcceptTcpClient. So a listener process that
is alive-but-wedged still SYN-ACKs: curl would connect and then hang waiting for the response body, and you
would see a read/total timeout, NOT a connect timeout. You measured connect-timeout x3 with no reset. That is
decided below my pwsh loop entirely, so an app-level wedge cannot produce it.

The one path from a wedged app to a genuine connect-timeout is BACKLOG EXHAUSTION -- a full accept queue makes
Windows drop new SYNs. TcpListener.Start() with no argument takes the platform default backlog (hundreds), and
the arm generated three fetches plus a handful of loopback probes. It cannot fill. So that path is closed too.
=> the loopback 000 is an instrument flicker, and E0 BLOCKED stands on the connect-phase evidence alone.

Two things I still want, both cheap, neither a re-run:
(1) liam: the curl EXIT CODE on the 01:04:22Z loopback 000. 7 (connection refused) vs 28 (timeout) separates
    "socket briefly gone" from "socket there, app slow" and classifies the flicker instead of leaving it
    unlabelled in the record. If it was 7 while netstat still showed the row, that is worth its own line.
(2) A caveat that recurs is a defect. If the 000 repeats in E1/E2/E3, my single-threaded listener is the
    suspect and I own it -- it handles one connection at a time and does no timeout on the client socket, so
    one half-open peer would stall the loop for as long as that peer holds it. It did not matter here for the
    reason above, but if E1 or E2 ADMITS and real connections start landing, a stalled loop CAN turn a genuine
    admit into a false timeout. If you see a second 000, stop the arm and ping me rather than logging it --
    I will hand liam a version that sets ReceiveTimeout/SendTimeout on the accepted socket.

E1 is the prediction I expect to be wrong about. Standing by.