fix(engine): inject the RST the way loopback packets actually travel

[donislawdev]

F15 - found by measuring the one thing the audit had never checked: what the application sees,
rather than what a counter says.

The finding

"Reset connections" did nothing to 127.0.0.1 connections. It blackholed them for the length of
the cooldown while reporting an RST as sent, so an application talking to a local service - a dev
server, a database, a proxy - sat there until its own timeout expired instead of seeing a reset.
For a test that expects a broken connection, that is the difference between "failed as designed"
and "hung".

run	result	counters
DNS over TCP to 8.8.8.8:53 (not loopback)	RESET at 6.6 s, WinError 10054	rst=1/1
own echo server on 127.0.0.1	TIMED OUT at 9.5 s, never reset	rst=5/1
127.0.0.1, after this fix	RESET at 6.5 s, WinError 10054	rst=1/1

The counter moving from 5/1 to 1/1 is independent confirmation: a connection that dies at once
has no further packets left to swallow during the cooldown.

It also closes the audit's oldest unverified claim. rst_sent was said to prove only that
send() did not raise. It proves more: Windows accepts the packet _build_rst_packet forges, and
the application's connection really dies.

Two hypotheses, one measurement each - and the first was wrong

1. A fresh pydivert.Packet starts with Loopback=0, so the flag was carried over from the
   provoking packet. One line on purpose - changing the direction at the same time would have
   made a success ambiguous. Re-ran the probe: TIMED OUT at 9.5s after 26 exchanges, the baseline
   to the exchange. Falsified.
2. Rather than guess a second time, the mechanism was measured. A sniff-only handle on
   loopback and tcp printed every packet of a real 127.0.0.1 conversation as
   outbound=1, loopback=1, exactly once each - the server's replies included. Loopback has no
   inbound presentation at all, so an RST injected as Direction.INBOUND was put on a path the
   stack never reads.

The RST is now built to look exactly like those captured rows: OUTBOUND with the loopback flag, for
loopback packets only. Ordinary traffic keeps INBOUND, which is measured to work and must not
change.

A measurement trap worth keeping

The first attempt fired on the SYN, because --rst-prob 100 catches the first packet of a flow,
and a bare RST with seq=0 and no ACK is ignored in SYN_SENT (RFC 793). That run measured the SYN
case, not the established one, and looked like "RST does not work". When testing behaviour on a
connection: establish it, pass some traffic, then switch the impairment on.

Verification

• python -m pytest tests -> 709 passed, 0 failed (elevated shell). python smoke_gui.py -> OK.
• New guard asserting direction and flag for both cases against a hand-built IPv4+TCP ACK,
  conditional on pydivert (win32-only) like the driver-queue ABI check. Three mutants, every one
  caught - including "every RST becomes a loopback one", which would have broken the ordinary path
  this fix must not touch.
• No hot-path change: this is the RST construction path, which runs once per reset.

🤖 Generated with Claude Code