fix(client): restore TAP media status on exit

The Windows client already treats TAP route, metric, and MTU changes as scoped
runtime state that is restored when the process exits. TAP media status was the
odd one out: startup marked the adapter connected, but there was no matching
cleanup path to mark it disconnected again.

Add a small TAP media guard that owns an Arc to the opened adapter and marks
media disconnected on drop. The frame pump now receives an Arc<TapAdapter>, so
the guard can run on normal Ctrl-C, startup errors after TAP open, route-check
failures, or frame-pump failures without fighting ownership of the TAP reader
thread. Cleanup errors are logged because Drop cannot return them.

Update the README and MVP test guide so the documented cleanup behavior matches
the client runtime.

The full Windows client cross-check is still blocked on this host before project
code by ring needing x86_64-w64-mingw32-gcc. The TAP and route helper crates
still check for the Windows GNU target.

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

Refs: MVP Windows TAP cleanup

TESTING.md

@@ -232,7 +232,7 @@ Uncommon LAN subnets such as `10.73.42.0/24` are safer than `192.168.0.0/24`.
 ## Cleanup
 
 Stop client, gateway, and relay with Ctrl-C. The Windows client restores the TAP
-route policy when it exits normally.
+route policy and marks TAP media disconnected when it exits normally.
 
 Keep `lanparty-client-identity.json` if you want the same virtual MAC on the
 next run. Delete it only when you intentionally want a new client identity.