Add RoomEvent.RoomSidChanged

[biglittlebigben]

Summary

• New RoomEvent.RoomSidChanged (args: sid: string), emitted from handleRoomUpdate when an update carries a non-empty session ID different from the last known one — e.g. the server starting a new session for a room that is still live, or a move. getSid() returns the new ID.
• Updates with an empty SID don't reset the known ID. The event goes through emitWhenConnected, so it is not emitted for the initial join and is buffered across reconnects.

Testing

• New room updates test in Room.test.ts; vitest, tsc and eslint pass. The Playwright smoke spec is not runnable locally (@playwright/test missing), same on main.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: b9eb1e6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
livekit-client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	114.36 KB (+0.02% 🔺)
dist/livekit-client.umd.js	123.58 KB (+0.02% 🔺)

[lukasIO]

this makes sense to me.

One question: how are users expected to react to this (if at all) or is it purely informational?
A RoomSidChange was previously implicit via a RoomMoved event. Now we're emitting both RoomMoved and RoomSidChange in short succession.
I'm wondering if it makes sense to include a reason param or similar in the RoomSidChange event in order for users to be able to infer why the Sid has changed (and potentially deduplicate the RoomSidChange with a following RoomMoved event in their event handling logic).
Afaict we would currently only be able to infer that it happens because of a room move, not sure if it's worth it though.

[biglittlebigben]

this makes sense to me.

One question: how are users expected to react to this (if at all) or is it purely informational? A RoomSidChange was previously implicit via a RoomMoved event. Now we're emitting both RoomMoved and RoomSidChange in short succession. I'm wondering if it makes sense to include a reason param or similar in the RoomSidChange event in order for users to be able to infer why the Sid has changed (and potentially deduplicate the RoomSidChange with a following RoomMoved event in their event handling logic). Afaict we would currently only be able to infer that it happens because of a room move, not sure if it's worth it though.

This currently happens in some pathological room lifecycle situations where we hear late that a room we thought was deleted actually had a participant connect to it. Clients who have logic that relies on the RoomID should take note. However in an ideal world the RoomID would not change in these cases. We are working on improving these situations but it may take a while as it involves a fairly large and risky change to the way we allocate IDs.

Egress particularly cares about this to make sure active egresses don't get swept. I can add a reason field, but what would be an appropriate reason for "race condition in room lifecycle logic"?