Rename the query parameter, function, and all related comments
from 'replay' to 'initChannelState' to better reflect the
semantics: the server initializes channel state for the
reconnecting client rather than replaying past events.
When a client reconnects to an existing session (e.g. browser tab
closed and reopened), the server now enqueues synthetic JOIN messages
plus TOPIC/NAMES numerics for every channel the session belongs to.
These are delivered only to the reconnecting client, not broadcast
to other users.
Server changes:
- Add replayChannelState() to handlers that enqueues per-channel
JOIN + join-numerics (332/353/366) to a specific client.
- HandleState accepts ?replay=1 query parameter to trigger replay.
- HandleLogin (password auth) also replays channel state for the
new client since it creates a fresh client for an existing session.
SPA changes:
- On resume, call /state?replay=1 instead of /state so the server
enqueues channel state into the message queue.
- processMessage now creates channel tabs when receiving a JOIN
where msg.from matches the current nick (handles both live joins
and replayed joins on reconnect).
- onLogin no longer re-sends JOIN commands for saved channels on
resume — the server handles it via the replay mechanism, avoiding
spurious JOIN broadcasts to other channel members.
Closes#60