feat(client): log filtered relay-to-TAP frames

Windows MVP debugging needs more than aggregate drop counters when LAN traffic
reaches the client but is kept out of the TAP adapter. A DHCP or discovery
failure is much easier to diagnose when the client log says which relayed frame
was filtered and why.

Expose a client receive outcome that preserves the existing accepted-frame API
while allowing the Windows frame pump to log filtered RelayToTap frames with
the source peer and drop reason. Document the new log signal in the README and
manual MVP test guide.

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

Windows-target check attempted:
- cargo check -p lanparty-client-win --target x86_64-pc-windows-msvc

The Windows-target check is still blocked on this Linux host before compiling
lanparty-client-win because ring cannot find the MSVC lib.exe tool.

Refs: MVP client diagnostics

README.md

@@ -285,9 +285,10 @@ also safety-checked before TAP writes, so switch-control traffic,
 invalid-source frames, jumbo frames, and over-TAP-MTU frames stay out of the
 Windows adapter even if they reached the client over QUIC.
 Misdirected unicast frames not addressed to the client's virtual MAC are also
-counted and skipped; accepted TAP-to-relay and relay-to-TAP frames are logged
-with direction, peer id, MACs, ethertype/length, frame length, action, and drop
-reason. TAP device read/write errors still stop the bridge.
+counted, skipped, and logged with the drop reason; accepted TAP-to-relay and
+relay-to-TAP frames are logged with direction, peer id, MACs, ethertype/length,
+frame length, action, and drop reason. 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
 and from the initial welcome, so later leave logs can identify a disconnected