fix(relay): seed gateways before join notifications

The relay used one accepted-peer handshake order for clients and gateways:
register the peer, notify existing peers, send the welcome, then send catch-up
events to the new peer. That is correct for a client joining an existing
gateway because the gateway must learn the client's MAC before the client can
send frames.

The same ordering is risky for a gateway joining a room that already has
clients. Existing clients could learn that the gateway is available before the
gateway has received the existing client MAC table. Reverse that part of the
sequence for gateways: send the gateway welcome, send existing peer catch-up
events to the gateway, then notify clients that the gateway joined.

Keep client joins on the old ordering, and keep handshake-failure cleanup quiet
for gateway welcome failures because clients have not been notified yet.

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

Refs: MVP gateway lifecycle ordering

README.md

@@ -153,9 +153,11 @@ 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. 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.
+`PeerJoined` events for peers that were already present. When a client joins,
+the relay notifies existing peers before the client receives its welcome, so
+gateways can seed client MAC state before that client starts sending frames.
+When a gateway joins, the relay gives the gateway the current client list
+before notifying clients that the gateway is available.
 
 ### MVP Trust Model