ddidderr
efda797ae6
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