feat: narrow the driver filter, and let the views follow the target

[donislawdev]

Chunks 1 and 2 of the throughput work. It turned out to be a correctness fix, not
the speed option it was designed as - see the acceptance table.

The problem

With a destination target set, the tool receives every packet on the machine and
re-injects almost all of it untouched. Measured against a real capture: 1944 packets
diverted, 0 of them even eligible to be impaired. Every one cost a recv plus a send
for nothing. The WinDivert filter runs in the driver, so whatever can be pushed
into it never reaches this process at all.

Acceptance, and the part worth reading twice

A flood to the targeted destination plus a decoy flood outside it:

run	narrowed	seen	scoped_seen	drop_loss	sent to target	receiver got
wide, no impairment	False	75 056	15 768	0	28 050	15 768
narrow, no impairment	True	27 950	27 950	0	27 950	27 950
wide, --loss 100	False	88 943	21 540	21 540	28 050	0
narrow, --loss 100	True	27 900	27 900	27 900	27 900	0

Without narrowing the driver was overloaded by traffic the tool was never going to
touch and discarded 43% of the TARGETED traffic before the tool saw it - so the
session impaired less than it claimed and computed its percentages over the
survivors. Narrowed: nothing lost, seen equals scoped_seen. The driver-wait
warning fired in both wide runs (52 / 184 ms) and in neither narrowed one - the same
overload from the other side.

The regression worth fearing did not happen: with --loss 100 the narrowed run
dropped 27 900 of 27 900 and the receiver got nothing, exactly as the wide run did.

How it is kept safe

The only invariant that matters: the driver filter must be a SUPERSET of the
matcher. Over-capture is free (decide() still filters); under-capture is a silent
regression - traffic the user asked to impair would never arrive, with every counter
reading healthy.

• only POSITIVE terms compile; dropping negatives can only widen
• one term with no closed description (glob, re:) voids the whole expression
• both directions are emitted - _capture_loop reads the remote endpoint as the
  DESTINATION outbound and as the SOURCE inbound, so a fragment testing only
  DstAddr/DstPort would have silently stopped impairing everything coming back.
  Caught by tracing writes, not by reading names.
• the result must COMPILE, asked of the driver's own parser
• process targeting can never be narrowed: processId is "bad token for layer" at
  NETWORK, checked rather than assumed

_Term now carries the parser's conclusion (shape) so the compiler reads the parse
result instead of parsing the same text twice - convention 10's concern is drift, and
two readers of one syntax stay in step only until one is edited.

The mid-session trap

dst_ip/dst_port are live-appliable; a handle's filter is not. Accepting a
destination change during a narrowed session would leave the driver filtering by the
old expression while decide() judged by the new one. apply_settings refuses a
changed destination out loud and leaves re-applying the same value alone.

Verification

• python -m pytest tests - 732 passed, 0 failed on an elevated shell (721 -> 732, eleven new guards).
• python smoke_gui.py - OK. tools/ci_gui_render.py - OK in both languages.
• Oracle checked before being trusted: WinDivertHelperEvalFilter agreed with 40
  real captured packets across 9 filters, including the address-dependent terms a blank
  address struct would have got wrong. Then every fragment was swept: 27 648 packet
  views over 16 expressions, zero superset violations.
• Eleven mutants across the two chunks. Nine caught. Two green ON PURPOSE, and both
  are the point: emitting only a range's lower bound is a widening and must not fail,
  and filter_compiles' exception path is unreachable where pydivert exists.
• A surviving mutant found a real hole: removing the compile check went green
  because nothing produced a fragment the driver would refuse. It exists - the grammar
  has a length limit, and a 100-port list hits it (50 compile, 100 do not). Without the
  check the handle would fail to open at START. Guarded now.
• The oracle test needs pydivert and is skipped without it - half the CI matrix.

Also in here

A Polish label typo the render check surfaced (invisible in code), and a measurement
with no code attached: WinDivertSendEx rejects a batch containing a malformed packet
atomically (pSendLen=0, nothing sent, 120 bytes of good packets ahead of it
included). That removes the one blocker named against the batched-injector chunk.

Also on this branch (added after the first review pass)

• A view preference, "Show only the targeted traffic" (off by default): the counter grid, the
  chart, the Connections table and the connections CSV narrow to what the targeting selected. Three
  counters never narrow - drop_overflow, drop_shutdown, drop_send count what the TOOL lost,
  including untargeted traffic - and the notes and the chart caption re-word themselves so a
  screenshot cannot be misread. The stats CSV keeps both totals (it is an append log); NDJSON and
  the reproduction report are untouched.
• A guard for every gate that judges the remote endpoint, in BOTH directions. Mutation showed
  the rule was caught only by three CONNECTION-LOG tests - nothing about targeting, LAN mode or
  blocking noticed. FakePacket also had src_port == dst_port, which made the port half of any
  such assertion vacuous; it takes them separately now.
• An accounting hole closed: a packet popped off the release heap and then found without a
  divert (STOP cleared it in between) vanished with no counter at all. It is charged to
  drop_shutdown now.
• The batched injector was built, measured and REVERTED - engine end to end 1.00x (7 of 14
  pairs, median 1.00, range 0.93-1.05). Instrumenting the real engine explains why: mean 2.13
  packets per batched call and peak_queue 30 against a 20 000 limit, because the inject thread
  keeps up and the release heap never accumulates. The ADR in CHANGELOG-INTERNAL names the number
  to re-measure before anyone reopens it.

Final state: 746 passed, smoke_gui.py OK, real-Tk render OK in both languages.

🤖 Generated with Claude Code