Refuse blocked TCP connections instead of dropping them in silence

[donislawdev]

A block answers nothing today, so the application under test waits out its own timeout.
That is one of the two failures a client can meet, and a suite that has only ever seen it
has tested half of them: a refusal comes back fast and usually goes down an error path or
an immediate failover. --block-reject, and a checkbox beside the block fields, forge the
reset a closed port would send.

The obvious version of this change ships a mode that does nothing. Step 2c runs BEFORE
the RST step, so the packet it holds is a SYN, and a reset built the old way goes out with
seq=0 and no ACK - which a stack in SYN_SENT is entitled to ignore (RFC 793), and did:
that measurement has been in core.py since 2026-07-28. Measured again before writing any
of this, against a real peer: the old shape left connect() hanging in 3 of 3 while three
resets went out and were discarded; RST|ACK acknowledging the SYN ends it with WinError
10061 in 3 of 3. The shipped tool was then measured the same way - 8012 ms of silence
without the flag, a refusal at 2008 ms with it.

Those two seconds are the stack's, not ours, and the copy says so: a genuinely closed
port on this machine answers in 2003 ms, with the same five SYN retransmits. The tooltip and
the README may say "instead of waiting out its own timeout" and may not say "instantly".

Outbound TCP only, and both limits are in the tooltip. An inbound SYN would have the
reset aimed at a connection the local stack does not have yet, so it would be discarded and
only the counters would move; UDP's refusal is an ICMP port-unreachable this tool does not
build.

Counted apart from rst_reset. That number means an established connection was cut and
put in cooldown, and it reaches users as connections_reset in the stats CSV and the
reproduction report. Refusals are connections_refused, and the report gains
blocked_refused: "23 packets blocked" does not say what the application actually met.
An existing stats CSV is rotated to a dated backup on the first write, as any new column
does here.

Two ceilings shaped the code rather than review. core.decide scores 27 against
max-complexity = 27, so the mode rides inside the existing return as a boolean
expression; _capture_loop is one of the twelve functions nested four deep against a
ratchet of twelve, so the engine picks its counter through a map instead of a branch.

Guards: four tests in test_rst_local.py, all four in MUTATIONS and run rather than
written - 4 of 4 caught, each by its own test. Field.parameter_of met its first
non-number and the pass-through sweep crashed on bounds[1]; fixed in the test, because a
checkbox's maximum is True, rather than by giving the field fake bounds.

Performance: bench is clean. The blocked path itself refused a verdict twice - the mode
measured 437 ns ahead in one paired run and 312 ns behind in the next, both inside their
own spread - so what it adds (one attribute read and two boolean operators, on a packet
already being dropped) is below what this machine can measure, and neither number is quoted
as a result.

🤖 Generated with Claude Code