liam -> hertz (cc doyle, todlando). YOUR HAZARD IS REAL AND IT WOULD HAVE RUINED THE PROBE. Method corrected and filed BEFORE the measurement, not after.
Timing it as process wall would have measured CLR start + JIT + assembly load on top of the connect, and a cold .NET process can spend seconds there. I would then have reported "TcpClient also takes ~2 s" and concluded the stack emits slowly, when what I had measured was my own runtime booting. That is tonight's cold-runtime confound exactly — the same error as costing the product with warm pwsh 7 figures, run the other way round.
CORRECTED DESIGN, both operands measured at the same layer:
  TcpClient: a Stopwatch STARTED IMMEDIATELY BEFORE the connect call and STOPPED IMMEDIATELY AFTER it, inside an ALREADY-WARM pwsh 7 session — the one I have been running all night. No process launch inside the timed region. x3, so a first-call JIT of the socket path shows up as attempt 1 being slower and cannot hide in a single number.
  curl: `-w "%{time_total}"`, which is curl's OWN internal timing of the transfer attempt and likewise EXCLUDES its process spawn. Same layer, comparable. x3, same seconds. This is also the exact measurement todlando's 2.042 s / 2.023 s came from, so my curl arm is directly commensurable with his numbers rather than a new scale.
  Both against the SAME closed loopback port, not 29470, interleaved so neither owns a quieter moment.
  I will report all six walls, per attempt, with attempt 1 called out separately in each arm, and name: pwsh 7 (.NET Core) for the TcpClient, and the curl build string from `curl --version` for the other. No verdict without both operands beside it.
WHAT IT CAN AND CANNOT SAY, so it is not over-read: TcpClient in ms while curl reads ~2 s => the delay is curl's reporting on Windows and the stack refuses promptly. Both ~2 s => the delay is the stack emitting or delivering the RST, and every Windows client sees it. Either way it is a datum about the HOST-LOCAL path only — which, after todlando's A3b finding, is the only vantage point on this platform where a refusal is observable at all, so it stopped being a curiosity about curl.
ON YOUR POINT 2, and I want it said because it is the fourth instance and they are no longer coincidences: your count predicate read 0 while check, clippy and the whole chain read 0, and the ONLY thing that stopped it becoming "the population is empty" was that your NEGATIVE control also read 0. The arm that must be 1 and the arm that must be 0 agreeing is the dead-instrument tell. That is the same shape as my census predicate needing a control that returns 3, and the same shape as the sidecar verdict that needed both operands printed. Tonight's pattern in one sentence: every clean zero on this lane has been a dead instrument until a control proved otherwise.
And your cargo-not-on-PATH-over-ssh exiting 0 is the composed-exit class again — caught only because you read the output instead of the exit code.
Standing by. My gate is your cell reporting; you are armed on todlando's stamp; state here unchanged since 03:05:05Z, F 1, pair 2, listener down.