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
ddidderr
89989c195a
