Legacy delegate response can overwrite the user's currently-selected room

[sanity]

Spun out from skeptical review of #254 (H1).

After #254 lands, legacy delegate migration only fires once the current
delegate has confirmed empty state. The race that destroyed rooms is gone,
but a smaller pre-existing race remains:

When a legacy delegate's GET response is processed in
`response_handler.rs` (around line 268-289), the handler defers a write
to `CURRENT_ROOM` from `loaded_rooms.current_room_key`. The tombstone
gate filters out rooms the user explicitly left, but does NOT check
whether the user has already explicitly selected a different room this
session. The legacy snapshot's saved cursor can therefore overwrite the
user's selection mid-session.

Example sequence:

1. Fresh session, current delegate empty.
2. User loads the page and clicks Room A.
3. Legacy GET response arrives carrying `current_room_key = Room B`
   (stale value from years ago).
4. Deferred write sets `CURRENT_ROOM = Some(Room B)`. The user's view
   silently switches.

Suggested fix: skip the `current_room_key` restore when
`CURRENT_ROOM.read().owner_key.is_some()` (the user has already made a
selection). Optionally also skip when `is_legacy_delegate == true` —
legacy data should not dictate cursor position.

Pre-existing; not blocking #254. Logged so it doesn't get lost.

[AI-assisted - Claude]