feat(client): persist TAP MAC identity

The Windows client already generates and announces a stable locally administered
MAC, but it only rejected the TAP adapter when the driver reported a different
address. Persist the tunnel MAC to tap-windows6's NetworkAddress registry value
before opening the adapter so the driver can load the intended current address.

The TAP crate now keeps the driver registry key name from discovery, formats the
NetworkAddress value as the 12-digit hex string expected by NDIS, and rejects
invalid multicast, broadcast, or globally administered MACs before writing.

Runtime validation stays in place. tap-windows6 reads NetworkAddress during
adapter initialization, so an adapter that Windows already initialized with an
old value may still need disable/enable or reinstall on the real Windows test
machine before the GET_MAC ioctl reports the new identity.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-client-tap
- cargo test -p lanparty-client-win
- cargo clippy -p lanparty-client-tap --all-targets -- -D warnings
- cargo check -p lanparty-client-tap --target x86_64-pc-windows-gnu
- cargo check -p lanparty-client-tap --target x86_64-pc-windows-msvc
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check

Refs: PLAN.md

README.md

@@ -74,6 +74,7 @@ Windows route-table boundary:
 Windows TAP adapter boundary:
 
 - TAP-Windows6 adapter discovery from the Windows network adapter registry
+- TAP `NetworkAddress` registry configuration for the tunnel MAC identity
 - `\\.\Global\{NetCfgInstanceId}.tap` device path construction
 - blocking Ethernet frame reads/writes through the TAP device handle
 - TAP driver IOCTL helpers for media status, adapter MAC, and MTU
@@ -162,7 +163,8 @@ with a generated locally administered virtual MAC persisted in
 handshake, pins a host route for the relay IP on the current pre-TAP interface,
 verifies that the relay route still uses that pinned host route after TAP
 activation, and then bridges Ethernet frames between the relay and the first
-TAP-Windows6 adapter until shutdown.
+TAP-Windows6 adapter until shutdown. Before opening the adapter, it writes the
+generated tunnel MAC to the TAP driver's `NetworkAddress` registry setting.
 The startup status reports whether the relay already has a LAN gateway for the
 room.
 `--virtual-mac` can still override the stored identity for manual testing. On
@@ -171,8 +173,10 @@ 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, periodically
 rechecks that the relay route remains pinned, then restores the previous route
-policy on exit. Until automatic TAP MAC configuration is wired, startup fails
-before bridging if the driver-reported MAC does not match the tunnel identity.
+policy on exit. Startup still fails before bridging if the driver-reported MAC
+does not match the tunnel identity, because an already-initialized Windows TAP
+adapter may need to be disabled/enabled or reinstalled before it reloads the
+configured `NetworkAddress`.
 It prints and reports client diagnostics snapshots with relay reachability,
 route-pinning, QUIC datagram budget, TAP status/IP, frame/datagram counters,
 and drops.