feat(client): bridge TAP frames in Windows client

Wire the Windows client run loop to move Ethernet frames between the relay
session and the opened TAP-Windows6 adapter. TAP reads use a named OS thread
because the current adapter API performs blocking synchronous reads; relay to
TAP writes use short `spawn_blocking` jobs so the async receive loop does not
block the Tokio worker.

The main function now always closes the relay session after the client run loop
finishes, including TAP pump errors. Ctrl-C still stops the client. The TAP
reader thread is intentionally detached in this first pump slice because a
blocking TAP read cannot yet be cancelled cleanly from the async side; process
exit tears it down after shutdown.

This still leaves route pinning and automatic TAP MAC/MTU configuration for
later. The README now reflects that frame pumping is wired while those Windows
network-configuration pieces remain outstanding.

Verification note: I attempted to check `lanparty-client-win` for
`x86_64-pc-windows-msvc`, but this Linux host still lacks the Windows C
headers needed by `ring`; the build stops at `assert.h` before the binary crate
can be typechecked for Windows.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- CC_x86_64_pc_windows_msvc=clang-cl AR_x86_64_pc_windows_msvc=llvm-lib \
  CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER=lld-link cargo clippy \
  -p lanparty-client-tap --target x86_64-pc-windows-msvc -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -121,7 +121,8 @@ cargo run -p lanparty-client-win -- \
 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. 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.
+handshake, 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. Route
+pinning and automatic TAP MAC/MTU configuration are not wired yet.