feat(client): monitor relay route after TAP activation

The Windows client now verifies that the relay path still uses the pinned host
route after the TAP adapter is activated, and keeps checking that invariant
while frames are being bridged. If Windows starts choosing a different prefix,
next hop, or interface for the relay IP, the client exits instead of silently
letting the tunnel route itself through the TAP side.

This closes the remaining detection half of the route-protection startup flow
from PLAN.md. The previous commits installed the pre-TAP host route, scoped TAP
metrics, and disabled TAP default routes; this commit proves those protections
are still winning after TAP activation and catches later DHCP-driven route
changes during the session.

The route crate now exposes small helpers for route-interface identity and host
route matching so the client does not duplicate route-prefix semantics inline.

The full Windows client target check still cannot complete on this Linux host:
`ring` fails while compiling for `x86_64-pc-windows-msvc` because the Windows C
header `assert.h` is unavailable, before `lanparty-client-win` is typechecked.
The independent Windows-target route crate checks do pass.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo check -p lanparty-client-route --target x86_64-pc-windows-msvc
- cargo clippy -p lanparty-client-route --target x86_64-pc-windows-msvc --all-targets -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -135,12 +135,14 @@ The Windows client binary currently connects to the relay as `role = client`
 with a generated locally administered virtual MAC persisted in
 `lanparty-client-identity.json`, completes the control-stream hello/welcome
 handshake, pins a host route for the relay IP on the current pre-TAP interface,
-and then bridges Ethernet frames between the relay and the first TAP-Windows6
-adapter until shutdown.
+verifies that the relay route still uses that pinned host route after TAP
+activation, and then bridges Ethernet frames between the relay and the first
+TAP-Windows6 adapter until shutdown.
 `--virtual-mac` can still override the stored identity for manual testing. On
 Windows it marks the TAP media connected and reports the driver MAC/MTU before
 forwarding frames, along with the TAP interface index/LUID. The client applies
 a scoped TAP interface metric and disables TAP default routes while it runs,
-then restores the previous route policy on exit. Until automatic TAP MAC/MTU
-configuration is wired, startup fails before bridging if the driver-reported
-MAC or MTU does not match the tunnel settings.
+periodically rechecks that the relay route remains pinned, then restores the
+previous route policy on exit. Until automatic TAP MAC/MTU configuration is
+wired, startup fails before bridging if the driver-reported MAC or MTU does not
+match the tunnel settings.