feat(client): open TAP adapter on Windows

The client can now reach the relay with a stable virtual MAC, and the TAP crate
can discover and open installed TAP-Windows6 adapters. Wire those pieces
together at startup so the Windows binary opens the first TAP adapter and marks
its media status connected after the relay handshake succeeds.

The binary reports the TAP device path plus the driver MAC and MTU. If those do
not match the tunnel identity or relay-selected MTU, it warns explicitly instead
of pretending configuration is complete.

Frame pumping and route protection remain separate follow-up slices. The full
Windows client binary still cannot be target-checked on this Linux host because
its QUIC/TLS stack needs Windows C headers for ring, but the TAP crate itself is
Windows-target checked and clippy-clean.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- Windows-target cargo clippy for lanparty-client-tap with -D warnings
- git diff --check

Refs: PLAN.md Windows TAP client

README.md

@@ -122,5 +122,6 @@ 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, and then waits for shutdown. `--virtual-mac` can still override the
-stored identity for manual testing. TAP adapter binding and route pinning are
-not wired yet.
+stored identity for manual testing. On Windows it opens the first TAP-Windows6
+adapter, marks media connected, and reports the driver MAC/MTU before waiting
+for shutdown. TAP frame pumping and route pinning are not wired yet.