fix(gateway): require announced MAC before LAN injection

The relay already enforces client source MAC identity before forwarding, but
this gateway bridge could still write any safety-clean relayed frame to
AF_PACKET. That left the final physical-LAN boundary depending entirely on the
relay forwarding path.

Keep a lifecycle-seeded remote client table in the gateway bridge and reject
relay frames whose datagram peer id is unknown or whose Ethernet source MAC does
not match the announced client MAC. CAM refresh now uses the same announced
table instead of learning source MACs from relay traffic.

This is conservative: if data arrives before the lifecycle event, the gateway
drops that frame with UnauthorizedSourceMac. Later packets proceed after the
control event is processed.

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

Refs: PLAN.md safety filters; TESTING.md MVP acceptance guide

TESTING.md

@@ -220,6 +220,10 @@ drop_reason=Ipv6RouterAdvertisement
 drop_reason=Ipv6Fragment
 ```
 
+On gateway `RemoteToLan` logs, `UnauthorizedSourceMac` means the relayed peer id
+did not match the client MAC announced by lifecycle events. If it repeats,
+check relay lifecycle logs and duplicate-MAC rejection first.
+
 ## Troubleshooting
 
 If the client says `Waiting for LAN gateway`, check that the gateway uses the