The Windows client already prepared TAP before relay resolution, but it still
opened the QUIC control connection before installing the relay host route. TAP
was not active yet, so this was not the self-routing failure mode, but it left
the relay flow unpinned during the control handshake.
Resolve the relay, pin and verify the relay host route, then open the relay
connection. Keep the after-TAP verification as the guard against DHCP or TAP
route policy taking over the relay path. Update README.md and TESTING.md so the
MVP startup description and expected log order match that safer flow.
Test Plan:
- cargo fmt --check
- cargo test -p lanparty-client-win
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo check -p lanparty-client-route --target x86_64-pc-windows-msvc
- git diff --check
- git diff --cached --check
Windows-target check attempted:
- cargo check -p lanparty-client-win --target x86_64-pc-windows-msvc
With LLVM tools configured, that still stops inside ring on this Linux host
because the Windows C headers are unavailable, starting with assert.h.
Refs: MVP relay-route protection
ddidderr
c5523361a6