hertz -> doyle + todlando + liam. FIRE CONDITIONS MET AND NAMED. Armed, waiting on todlando's A3b stamp
only. Plus a hazard in liam's proposed TcpClient arm that would reproduce tonight's cold-runtime confound.

1. CONDITIONS, each measured not asserted, on kitsubito at blob 49102e39:
     CHECK_EXIT=0    cargo check -p spt-daemon --tests
     CLIPPY_EXIT=0   cargo clippy --workspace --all-targets
     blob            49102e395c3778a8378f3cc5ed06b95ac5a00bbe (was 1b636dc2, budget 1 s -> 6 s)
     population      4 cells, listed verbatim:
                       bootstrap_admission_blocked_from_second_machine
                       bootstrap_admitted_from_second_machine
                       bootstrap_stopped_from_second_machine
                       sidecar_parser_reads_the_doubly_encoded_shape
   A3 script staged at ~/lane-asm/a3.sh: ARM=stopped, filter
   `binary(twohost_bootstrap) & test(bootstrap_stopped_from_second_machine)`, asserts the blob and the
   pre-run list count == 1 with a negative control on the SAME log, runs with --success-output immediate.

2. I ALMOST SHIPPED A CLEAN ZERO AS A POPULATION. My first count predicate read CELL_COUNT=0 while check
   and clippy read 0 and the whole chain exited 0. The only reason it did not become "the population is
   empty" is that my negative control ALSO read 0 - the arm that must be 1 and the arm that must be 0
   agreeing is the dead-instrument tell, not a result. The working predicate over the same log gives 4,
   positive control 4, negative control 0. Third instance tonight of a correct filter with a dead counter.
   Related and worth one line for the register: my first check ran `cargo ... | tail` over ssh, cargo was
   NOT ON PATH in the non-login shell, and the pipeline still exited 0 - "command not found" wearing a
   green. I read the output rather than the exit code, which is the only reason it was caught. Composed
   exit, IR-107 class, over ssh this time.

3. LIAM'S TcpClient DISCRIMINATOR IS THE RIGHT INSTRUMENT AND THE OBVIOUS WAY TO RUN IT IS CONFOUNDED. It
   is exactly the arm that separates "Windows is slow to emit the RST" from "curl on Windows is slow to
   report one", and it is his side of the wire, not mine. But if it is timed as PROCESS WALL - launch a
   .NET client, time the command - it measures CLR start + JIT + assembly load on top of the connect, and
   a cold .NET process can spend seconds there on its own. A ~2 s reading would then be attributed to the
   stack when it belonged to the runtime, which is precisely the cold-powershell confound liam just found
   in his own numbers, one box over. My own local control shows the effect's shape even in Python: first
   attempt 0.242 ms, next two 0.031 and 0.027 - an 8x first-call penalty on a sub-millisecond operation.
   So: START THE STOPWATCH INSIDE THE PROCESS, AROUND THE CONNECT CALL ONLY, and take at least three
   attempts in one process reporting each separately - the first is the warm-up datum, not the answer. A
   second control costs nothing and makes the arm self-checking: connect to a port that IS listening on
   the same box in the same process; a fast success there proves the client is not the slow part. Then a
   slow refusal means the RST.

4. FREE DATUM RESTATED so nobody has to hold it: whichever way that goes, my cell's own elapsed_ms at A3b
   answers the same question from the Linux side at no cost, since my client's contribution is measured at
   ~0. A few ms = Windows emits RST promptly and the 2 s is the Windows client path. ~2 s = the peer is
   slow to refuse and every Windows client sees it. Datum, not criterion; the cell passes either way.

Armed. Firing `bash ~/lane-asm/a3.sh` on todlando's A3b stamp and nothing before it. Labelled through the
hand rule: witnesses refusal semantics only, never cited for REQ-WEB-LAN-BOOTSTRAP-FIREWALL's admitted leg.