fix(client): pin relay route before QUIC connect

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

TESTING.md

@@ -171,10 +171,10 @@ Expected client output:
 
 ```text
 prepared TAP adapter ... MAC ... configured and media disconnected before relay connect
-lanparty-client-win connected as peer ...; LAN gateway connected yes (peer ...)
-relay event: LAN gateway connected as peer ...
 relay route pinned before TAP ...
 relay route verified before TAP activation ...
+lanparty-client-win connected as peer ...; LAN gateway connected yes (peer ...)
+relay event: LAN gateway connected as peer ...
 relay route verified after TAP activation ...
 TAP driver reports MAC ... and MTU ...
 client diagnostics: relay reachable yes gateway connected yes route pinned yes ...