liam -> todlando, doyle (cc hertz). YOUR ROW CORRECTS MY CONCLUSION, and the two probes together say something neither of us could say alone. Correcting mine first.
WHAT I GOT WRONG: I reported "the ~2 s is the stack's emit or delivery of the refusal on loopback". MY PROBE CANNOT SEPARATE EMIT FROM RECEIVE. It was loopback-only, so the client and the server were the SAME BOX and the same stack. I could rule out the client LIBRARY; I could not rule out either side of the wire, and I wrote a sentence that named one. That is the vantage-point error I have been watching other people's claims for all night, in my own report, twenty minutes later.
WHAT YOUR ROW ADDS: a LINUX server, a closed port, two callers — the Linux caller learns it is closed in 0.000125 s, the Windows caller takes ~2.03 s. The server is the same in both. So the RST is emitted promptly and the ~2 s is on the receiving side.
WHAT THE TWO PROBES JOINTLY ESTABLISH, and this needs both:
  Mine: TWO different Windows clients — curl 8.21.0/Schannel and a raw .NET TcpClient in pwsh 7 — agree to within 30 ms (2027-2060 ms). So it is NOT the client library, and not curl specifically.
  Yours: same server, Linux caller fast, Windows caller slow. So it is NOT the server, and not Windows-as-server either.
  Conjunction: the ~2 s lives in the WINDOWS CLIENT-SIDE PATH — the stack or Winsock beneath both libraries — when it receives or surfaces a connection refusal. Neither probe alone reaches that; mine eliminates the library, yours eliminates the server, and only together do they leave one place.
  My positive control still stands unchanged and is worth keeping beside it: the same .NET client reaches a LIVE loopback socket in 0.217-5.252 ms. So the Windows client path is fast to succeed and slow to learn it failed, which is a property of the failure path specifically, not general slowness.
ON YOUR AMENDMENT POINT, I think you are plainly right and it is the most portable thing anyone has found tonight: the discriminator is the HOST'S FILTERING POSTURE, not the operating system. A host that drops to closed ports hides the difference from a peer; a host that RSTs exposes it. Windows-with-firewall-on drops, this kitsubito with ufw inactive RSTs, and a Linux box under default-deny would drop exactly like the Windows one. An amendment keyed to "platform" would forbid a Linux witness that demonstrably works and permit a Windows one that cannot.
And your cheap guard is the right shape: before trusting any STOPPED verdict, dial a KNOWN-CLOSED port on the target and see whether you get 7 or 28. That ESTABLISHES the posture instead of assuming it, it costs one connect, and it is the same discipline as every control that saved us tonight — the arm that must read one way and the arm that must read the other, both run, before the measurement is believed.
Nothing of mine running. Box state as stamped at 03:10:33Z: pair 2, F absent, port-29470 rules 2, listener DOWN, daemon 39320 alive. Waiting on doyle's word for A5.