fix(gateway): refresh CAM on client joins

The gateway already emits periodic CAM refresh frames so the physical switch
keeps remote client MACs on the gateway port. A newly joined client previously
waited until either its own tunneled traffic reached the LAN or the first
60-second refresh tick fired.

Emit one padded CAM refresh frame immediately when a valid client PeerJoined
control event is observed. This makes the switch MAC-table check in the MVP
procedure visible sooner and keeps the periodic refresh as the aging guard.
The refresh uses the same maintenance frame shape as the periodic path and is
logged with the client peer id and MAC.

README.md and TESTING.md now document the immediate refresh behavior and the
log signal to look for during manual LAN testing.

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

Refs: PLAN.md CAM refresh; TESTING.md MVP switch MAC-table check

README.md

@@ -195,7 +195,8 @@ wired interfaces whose sysfs carrier state reports no link; managed wireless
 NICs are not supported for the physical LAN bridge.
 It tracks remote-client MACs from relay lifecycle events and periodically emits
 small CAM refresh frames so the physical switch keeps those MACs associated
-with the gateway port. Gateway
+with the gateway port. A newly observed client also triggers an immediate CAM
+refresh frame instead of waiting for the first periodic refresh tick. Gateway
 frame logs include direction, peer id when present, MACs, ethertype/length,
 frame length, action, and drop reason. The gateway also tracks frame/datagram
 counters and periodically sends stats snapshots to the relay. Malformed or runt