Catch-up lifecycle events to the newly joined peer are part of the accepted
handshake. They seed the peer's view of room membership before the rest of the
room can rely on that peer being ready.
The gateway-join ordering already sends the current client list to a new
gateway before notifying clients that a gateway is available. Make that delivery
mandatory: if the relay cannot send the catch-up event stream, clean up the
accepted peer and fail the handshake instead of publishing an incompletely
seeded gateway. The same required catch-up behavior applies to newly joined
clients after their welcome.
Existing-peer join/leave notifications remain best effort; a stale existing
peer should not prevent the relay from accepting healthy joins.
Test Plan:
- cargo fmt --check
- cargo test -p lanparty-relay
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check
- git diff --cached --check
Refs: MVP lifecycle ordering
ddidderr
4179d26f17