fix(crash,gui): record the next GUI crash, and remove two unsafe things found next to it

[donislawdev]

What this is

A GUI crash left Windows fatal exception: access violation inside tkinter mainloop with no Python frame above it and no session running. This branch makes
the next one diagnosable, fixes two unsafe things found while reading the code
around it, and settles a design question about who is allowed to name the process
in the connection table.

Everything below that says "measured" was measured on a real machine, with the
instrument kept in the repository's private rig directory. Nothing here claims to
have found the cause of that crash.

The crash, made diagnosable

crashlog.arm_native() had exactly one caller - engine.start, on the
real-driver path - justified by a docstring saying a native crash "can only come
from the WinDivert KERNEL DRIVER". That is not true of a Tk process. The crash
report that prompted this exists at all only because that process had started a
capture earlier in its life and arming never disarms.

cli._run_gui now arms as well, before the tkinter import: importing Tk is
itself a native surface, and arming after it would make the guard vacuous on a
runner without Tk.

crashlog.breadcrumb() adds what such a report cannot carry. The context provider
is only ever read by a Python-level failure, so a hard crash says nothing about
what the tool was doing; page, session state and open windows are written before
they are needed and removed with the native file on a clean exit. It is called
from the GUI tick - the one call site that cannot be forgotten when a fourth piece
of state appears - which is affordable only because the de-duplication lives in
crashlog, so an unchanged state costs a dict comparison and no disk.

Verified end to end: a clean exit leaves nothing behind, and a hard exit that
skips atexit leaves both files with the state in them.

gui/crash.py is new because gui/app.py sat exactly on the size ratchet's file
ceiling, and that guard's documented answer is to move code rather than raise the
number. The report context moved with the breadcrumb - they are the two halves of
one job, pulled and pushed.

Two hazards, both measured before being called hazards

gui/theme.py called user32 and dwmapi with no prototypes at all, while a
third function in the same module declared its own properly. This is the class
that already crashed this project once: a truncated 64-bit handle in
driver._advapi and an access violation on CI.

Measured before writing the fix, and the answer is narrower than expected.
GetParent returns the same value either way, and so does the window-style read
for the root window and for a withdrawn Toplevel - the only two shapes
disable_maximize is called on, replayed in its exact order. It differs for a
WS_POPUP window: a transient dialog and the tooltip bubble both have the top bit
set, so ctypes' default signed 32-bit result type reads them as negative.
Reachable, not currently reached - a property of today's call sites rather than of
this code, and one transient non-resizable window would end it.

The bindings move to winenv.user32() / winenv.dwmapi() with full prototypes.
They live there rather than in the GUI because they are Win32 rather than Tk, and
because a guard on them must not need tkinter or it is vacuous on the Linux
runner.

gui/tooltip.py could create a window inside Tk's destroy cascade.
Tooltip._hide is bound to <Destroy>, and _hide_bubble went through the path
that builds a Toplevel when the cached one is gone. Reproduced on real Tk rather
than argued: destroying a window with its bubble still showing creates nothing,
but destroying the bubble first and then the window built a fresh Toplevel inside
the cascade every time. That ordering needs no special setup, since the bubble is
a child of the toplevel it belongs to.

The same cache also grew without bound - keyed by toplevel name, and Tk does not
reuse names within a session, so every window ever opened left an entry holding a
dead Toplevel and Label. Measured at 25 dead entries after 25 open/close cycles,
1 after the fix.

Who names the process in the connection table

The impairment gate resolves against one table - the live socket-event map - while
the connection table's process and PID columns ask that map first and the poller
second, and the GUI then has a third source of its own. So the display can name an
owner the gate never saw, and nothing guarded the difference.

Measured across five sessions with real traffic: the live map answers 97.7-99.3%
of lookups, the poller answers alone for 0-3 ports per run, and in every one of
those the port had a close event with no matching open - a socket already there
when the watcher started. The two sources were never seen disagreeing about a port
the live map went on to learn.

So the fallback names the last known owner of an ended flow, which the live map
deletes on purpose, rather than guessing about a live one. It stays. The strict
variant was rejected because it would cost ended flows their name and lengthen a
per-packet retry, measured at 4.2-5.2 owner lookups per connection row.

The share must not be quoted: the first run gave 14.4% and the next four gave 1.3,
1.7, 2.3 and 0.0. It tracks how much the machine had open before the session
started, which is not a property of anything under test. The shape repeated, and
that is the finding.

The tooltip on that column now says when its answer was taken - the column was
described in the present tense while the name is read once and never re-checked,
which is why a row can still name a program that has since closed.

Guards

New: tests/test_native_prototypes.py and tests/test_owner_attribution.py, plus
three tests for the tooltip and six for the crash path. Eleven new entries in the
mutation registry, every one of them shown to redden the test it names.

Two of those mutations survived at first, and both were information about the
test rather than about the code. The bubble-pruning one, because the fake tkinter
had no winfo_toplevel so every widget shared one cache key - which had also been
making an existing test pass for the wrong reason. The targeting one, because the
real process-wide port table answers nothing for an unused port, so a gate that had
grown a second source underneath looked identical to one that had not.

Both new guards are written as rules rather than examples: one walks the binding
factories and scans the package for any native call made without a prototype, the
other scans for any new consumer of the owner lookup. Adding either without a
decision goes red on its own.

Three things fixed that this branch did not break

An assertion that could never fail: restype is not None for a ctypes function.
It defaults to c_long, and on Windows that is the same object as c_int and as
BOOL, so a truncated handle and a correctly declared boolean are
indistinguishable. That line had been sitting beside the fix for the original
access violation ever since. The width of a result is checkable, and that is what
it checks now.

Two driver tests read a real process-wide mutex despite monkeypatching everything
else, so they failed whenever any session of this tool was live on the machine.
Verified as pre-existing by running them at the commit before this work.

And the root cause behind that: the suite itself leaked the mutex. One test takes
it and then monkeypatches the release path, so the handle survived for the rest of
the pytest process. Watched through two full runs - free, held, free, held. A real
session started right after the tests would have stood down for an instance that
no longer existed. It is released in a fixture now, so the next test to take it
inherits the guarantee.

Checks

Full suite green (1018 passed), GUI smoke green, and the repository's own
pre-commit script reports ready.