fix(gateway): prioritize lifecycle events before frames

Gateway filtering and CAM refresh depend on the remote-client MAC table that
is seeded by relay lifecycle events. If a lifecycle stream and packet work are
both ready in the same loop turn, handle the lifecycle event first so the local
MAC table is as fresh as possible before deciding whether to inject or forward
frames.

This does not create a cross-stream ordering guarantee. It is a local scheduling
preference that reduces first-packet drops after client joins without weakening
source-MAC authorization or LAN-destination filtering.

Test Plan:
- 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: PLAN.md MVP gateway lifecycle and L2 bridge behavior

README.md

@@ -196,7 +196,10 @@ 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. Gateway
+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
 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