feat(client): disable TAP default routes while running

The Windows client now holds scoped default-route suppression guards for the
TAP interface while the frame pump is active. IPv4 protection is required,
matching the relay-route safety path. IPv6 protection is still best-effort so
IPv4-only Windows TAP setups do not fail startup just because there is no IPv6
interface row to update.

This completes the current client-side route-policy wiring from PLAN.md: the
relay host route is pinned before TAP activation, TAP interface metrics are
raised while running, and TAP default routes are disabled until the client
exits or startup unwinds. Automatic TAP MAC and MTU configuration remain
follow-up work.

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

@@ -140,6 +140,6 @@ 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 while it runs and restores the previous metric on
-exit. Default-route takeover detection and automatic TAP MAC/MTU configuration
-are not wired yet.
+a scoped TAP interface metric and disables TAP default routes while it runs,
+then restores the previous route policy on exit. Automatic TAP MAC/MTU
+configuration is not wired yet.