fix(client): fail fast on TAP identity mismatch

The Windows client now validates the driver-reported TAP MAC and MTU before it
marks the adapter media connected or starts bridging frames. If the TAP driver
settings do not match the tunnel identity and relay-selected MTU, startup fails
with a direct error instead of continuing into a session that would drop frames
or advertise the wrong L2 identity.

This is intentionally a correctness guard, not automatic configuration yet.
Until TAP MAC and MTU configuration are wired, the safe behavior is to fail
before traffic can flow. Route protection is still applied before validation and
restored if validation fails during startup.

The full Windows client target check still cannot complete on this Linux host:
`ring` fails while compiling for `x86_64-pc-windows-msvc` because the Windows C
header `assert.h` is unavailable, before `lanparty-client-win` is typechecked.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-client-win
- cargo clippy -p lanparty-client-win --all-targets -- -D warnings
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -141,5 +141,6 @@ adapter until shutdown.
 Windows it marks the TAP media connected and reports the driver MAC/MTU before
 forwarding frames, along with the TAP interface index/LUID. The client applies
 a scoped TAP interface metric and disables TAP default routes while it runs,
-then restores the previous route policy on exit. Automatic TAP MAC/MTU
-configuration is not wired yet.
+then restores the previous route policy on exit. Until automatic TAP MAC/MTU
+configuration is wired, startup fails before bridging if the driver-reported
+MAC or MTU does not match the tunnel settings.