fix(client): fail fast outside Windows

The MVP client only has a real TAP and route-protection runtime on Windows. A
non-Windows build was able to connect to the relay as a no-TAP client and then
wait for control events, which could consume a room slot while giving the false
impression that the Windows client path had been exercised.

Reject normal runtime startup on non-Windows platforms before reading tunnel
inputs or joining the relay. Keep non-Windows builds useful for type checking,
and document that they are not runnable tunnel clients.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-client-win
- cargo check -p lanparty-client-win
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo run -p lanparty-client-win -- --relay 127.0.0.1:1 \
  --relay-ca-cert /tmp/does-not-matter.der --room ROOM1
- git diff --check
- git diff --cached --check

Refs: MVP Windows TAP client boundary

README.md

@@ -235,8 +235,12 @@ cargo run -p lanparty-client-win -- \
   --room ROOM1
 ```
 
-The Windows client binary currently connects to the relay as `role = client`
-with a generated locally administered virtual MAC persisted in
+The Windows client binary is runtime-gated to Windows because the real client
+path depends on TAP-Windows6 and Windows route protection. Non-Windows builds
+are useful for type checking, but they fail before tunnel setup instead of
+joining a room without a TAP adapter. On Windows, the binary connects to the
+relay as `role = client` with a generated locally administered virtual MAC
+persisted in
 `lanparty-client-identity.json`. Before resolving or connecting to the relay,
 it writes the generated tunnel MAC to the selected TAP driver's
 `NetworkAddress` registry setting and marks TAP media disconnected. That clears