234bece265
The relay should only send a remote client unicast traffic for that client's virtual MAC, while broadcast and multicast traffic fan out to every relevant peer. The Windows client is still the last boundary before TAP, so it should not write a relayed unicast frame for some other MAC into the adapter if the relay or a future code path misroutes it. Add a receive-side destination guard in client-core. Relayed frames now reach TAP only when their destination is the client's virtual MAC or a broadcast/multicast address; other unicast frames are counted and skipped. Extend the client relay-session test with a wrong-client unicast before the valid frame, and document the client-side skip 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 frames to matching remote clients