fix(client): filter relayed LAN frames before TAP writes

LAN-to-remote switch-control filtering is enforced by the gateway and relay,
but the Windows client is the final boundary before frames enter the TAP
adapter. A malformed or buggy relay path should not be able to make the client
write LAN control traffic, invalid-source frames, or jumbo frames into TAP.

Reuse the shared gateway/LAN safety classifier on received relay Ethernet
frames. Filtered frames are counted and skipped, and recv_ethernet only returns
frames that are safe to hand to the platform TAP writer.

Extend the client relay-session test so the mock relay sends a filtered frame
before the valid one, then document the receive-side TAP boundary in the
README.

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

Refs: PLAN.md LAN-to-remote control-plane filtering

README.md

@@ -260,7 +260,10 @@ read from TAP, invalid or unauthorized source-MAC frames, L2 control-plane
 traffic, remote VLAN tags, DHCP server replies, IPv6 Router Advertisements, IPv6
 fragments, 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.
+stopping the bridge. Relayed LAN frames are also safety-checked before TAP
+writes, so switch-control traffic, invalid-source frames, and jumbo frames stay
+out of the Windows adapter even if they reached the client over QUIC; 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