fix(client): enforce virtual MAC before relay send

The relay already rejects client frames whose source MAC does not match the
announced virtual MAC. The Windows bridge can still see those frames from TAP,
though, and sending them to the relay wastes datagram budget and makes the
client-side counters less useful during manual tests.

Carry the configured virtual MAC into ClientRelayIo and drop invalid or
unauthorized TAP source MACs before QUIC DATAGRAM encoding. The relay keeps the
same checks as the trust boundary, but client diagnostics now account for these
drops locally.

Document the local source-MAC check and list InvalidSourceMac as a suspicious
manual-test drop reason.

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

Refs: PLAN.md source-MAC authorization and safety filters

README.md

@@ -61,8 +61,8 @@ Platform-neutral remote client relay session:
 - QUIC DATAGRAM support and negotiated datagram budget diagnostics
 - relay RTT diagnostics from the active QUIC connection
 - reliable relay control-event reads for peer lifecycle messages
-- Ethernet frame send/receive helpers over QUIC DATAGRAM with budget checks and
-  local drop outcomes for malformed or oversized sends
+- Ethernet frame send/receive helpers over QUIC DATAGRAM with budget and source
+  MAC checks plus local drop outcomes for malformed or oversized sends
 - client tunnel statistics for frame/datagram rx/tx and drops
 - reliable client stats snapshot sends for relay diagnostics
 - best-effort graceful disconnect messages before QUIC close
@@ -220,6 +220,9 @@ the first TAP-Windows6 adapter until shutdown. `--relay` accepts a DNS name or
 socket address; bare hosts default to UDP/443. Before opening the adapter for
 bridging, it writes the generated tunnel MAC to the TAP driver's
 `NetworkAddress` registry setting.
+TAP frames whose source MAC does not match that generated tunnel MAC are
+dropped locally before they can consume relay bandwidth; the relay still
+enforces the same source-MAC rule.
 If the exact relay host route already exists, the client uses it and leaves it
 alone on exit. The startup status reports whether the relay already has a LAN
 gateway for the room.
@@ -248,9 +251,10 @@ after bridging starts become visible in later status lines. Each snapshot also
 emits short user-facing lines such as relay/gateway connection status,
 relay-route and TAP readiness warnings, DHCP address presence, relay RTT, and
 broadcast-flow confirmation when those signals are observed. Malformed frames
-read from TAP, jumbo frames, and TAP frames whose encoded datagrams exceed the
-negotiated QUIC budget are counted and dropped before relay send without
-stopping the bridge; TAP device read/write errors still stop the bridge.
+read from TAP, invalid or unauthorized source-MAC frames, jumbo frames, and TAP
+frames whose encoded datagrams exceed the negotiated QUIC budget are counted and
+dropped before relay send without stopping the bridge; TAP device read/write
+errors still stop the bridge.
 Relay lifecycle events are logged as they arrive, including gateway joins and
 peer leaves. The client remembers peer identities from join and catch-up events
 so later leave logs can identify a disconnected LAN gateway or client MAC when