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

TESTING.md

@@ -289,8 +289,14 @@ Broadcast sent toward LAN; waiting for LAN broadcast reply
 LAN broadcast received
 client frame direction=TapToRelay ... action=Forwarded drop_reason=-
 client frame direction=RelayToTap ... action=Forwarded drop_reason=-
+client frame direction=RelayToTap ... action=Filtered drop_reason=UnknownDestination
 ```
 
+A filtered `RelayToTap` line means the client received a relay frame but kept it
+out of the TAP adapter. Occasional unrelated unicast can be normal; repeated
+filtered DHCP, broadcast, or LAN-game traffic is worth investigating with the
+drop reason.
+
 Drops that can be normal during testing:
 
 ```text