feat(gateway): log periodic CAM refreshes

The gateway already sent periodic CAM refresh frames so the physical switch
keeps remote client MACs learned on the gateway port. Those periodic refreshes
were silent, which made the manual MVP switch-learning check harder to diagnose
after the initial peer-joined refresh had passed.

Keep the peer id and MAC attached to periodic refresh work and emit the same
structured CAM refresh log line with reason=periodic. The join-triggered
refresh still logs reason=peer_joined, so the test guide can distinguish the
immediate proof from the recurring keepalive signal.

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

Refs: MVP switch MAC-learning diagnostics

README.md

@@ -198,12 +198,13 @@ The gateway rejects Linux interfaces that sysfs identifies as Wi-Fi, and rejects
 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. A newly observed client also triggers an immediate CAM
-refresh frame instead of waiting for the first periodic refresh tick. When
-control events and frame work are both ready, the bridge handles the lifecycle
-event first so first packets after a client joins use the freshest remote-MAC
-state available locally. Gateway
+small CAM refresh frames, logged with `reason=periodic`, so the physical
+switch keeps those MACs associated with the gateway port. A newly observed
+client also triggers an immediate CAM refresh frame logged with
+`reason=peer_joined` instead of waiting for the first periodic refresh tick.
+When control events and frame work are both ready, the bridge handles the
+lifecycle event first so first packets after a client joins use the freshest
+remote-MAC state available locally. 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