fix(relay): seed peers before join welcome

The gateway authorizes remote-to-LAN frames from the relay lifecycle table. A
new client can start sending Ethernet datagrams as soon as it receives its
welcome, so the relay should notify already-present peers before returning that
welcome to the joining peer.

Register the accepted peer, send the PeerJoined event to existing peers, and
then send the welcome to the joining peer. If the welcome write fails after the
pre-notification, remove the accepted peer and send PeerLeft so existing peers
do not retain stale client MAC state.

This still is not a cross-connection delivery proof, but it puts the relay-side
ordering in the right direction for first DHCP/ARP frames after a client joins.

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

Refs: PLAN.md MVP relay lifecycle and gateway MAC learning

README.md

@@ -147,7 +147,9 @@ Unknown unicast from a client is forwarded only to the gateway port; unknown
 unicast from the gateway is dropped instead of flooded to every remote client.
 When a peer joins or leaves, the relay sends a reliable lifecycle control event
 to peers that are still present in the room. Newly joined peers also receive
-`PeerJoined` events for peers that were already present.
+`PeerJoined` events for peers that were already present. Accepted joins notify
+existing peers before the joining peer receives its welcome, so gateways can
+seed client MAC state before a freshly accepted client starts sending frames.
 
 ### MVP Trust Model