feat(relay): notify peers when rooms change

The relay now sends a reliable PeerJoined control event to peers that were
already present in the room after a new peer completes the hello/welcome
handshake. Events are sent on one-frame unidirectional QUIC streams, reusing the
existing control codec without keeping the room/session lock across I/O.

Delivery is best-effort for this first lifecycle slice: a notification failure
is logged, but the newly accepted peer remains joined. PeerLeft delivery and
client-side event consumption remain separate follow-up work.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-relay forwards_ethernet_datagrams_between_joined_peers \
  -- --nocapture
- 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

Refs: PLAN.md

README.md

@@ -84,6 +84,7 @@ Public relay binary and relay-owned room state:
 - one gateway per room, duplicate client MAC rejection, and room limits
 - stable effective room MTU chosen before Ethernet datagrams flow
 - live Ethernet datagram forwarding with no ingress reflection
+- reliable `PeerJoined` notifications to existing room peers
 - L2 safety filters for jumbo, switch-control, DHCP-server, and IPv6-RA frames
 - client broadcast/multicast, unknown-unicast, and total bandwidth limiting
 - malformed peer datagram disconnect threshold
@@ -111,6 +112,8 @@ certificate handling remains future work. Ethernet forwarding decisions are
 logged with room, peer, MAC, ethertype, action, drop reason, and target count.
 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, the relay sends a reliable `PeerJoined` control event to
+peers that were already present in the room.
 
 ## Gateway