Fixes #247 (Ivvor's report 2026-05-14 17:03 — "every time i leave the
private room on the second node it's coming back after a refresh a
little while later").

## Root cause

`Confirm Leave` in `ui/src/components/room_list/edit_room_modal.rs:283`
did:

    ROOMS.write().map.remove(&room_vk);
    // … save_rooms_to_delegate()

On the next page load the UI re-fetches `rooms_data` from the current
delegate (correctly without the room) AND `fire_legacy_migration_request()`
probes all 17 entries in `legacy_delegates.toml`. Some legacy delegate's
on-disk `rooms_data` still contained the room — that data was never
purged when the delegate was superseded. `Rooms::merge` is purely
additive (`ui/src/room_data.rs:881`), so the room came back.

## Fix

Add a `removed_rooms: HashSet<VerifyingKey>` tombstone set to the
serialised `Rooms` struct (with `#[serde(default)]` for backward
compatibility). `Rooms::merge` now:

1. Takes the union of `removed_rooms` from both sides first.
2. Drops any entry from `self.map` whose key is in the union
   (defensive — should not happen if leave is the only mutation
   path, but enforced so the invariant holds).
3. Filters incoming entries from `other.map` against the union.

New `Rooms::leave_room(vk)` helper does both `map.remove(vk)` AND
`removed_rooms.insert(vk)` atomically. The Confirm-Leave button calls
this. Invitation acceptance (`get_response.rs` after PUT) clears the
tombstone with `rooms.removed_rooms.remove(&owner_vk)` so explicit
rejoins work.

## Tests

`leave_room_tombstone_prevents_merge_re_adding` — full scenario from
the report: room in map → `leave_room` → legacy merge with same room
present → must not re-add. Asserts both `map` and `removed_rooms`
invariants.

`merge_unions_removed_rooms_tombstones` — if either side has the
tombstone, it's honoured; map entries on the receiver are dropped.

14/14 UI `room_data::tests` pass (was 12).

## Deploy footprint

UI-only change. `chat_delegate.wasm` and `room_contract.wasm` are
BYTE-IDENTICAL to #245. No migration entry needed. No riverctl
republish. Deploy is `cargo make publish-river`.

## Recovery for currently-stuck users

After this lands and users reload, the next time they leave a room
the tombstone is recorded. Their previous leave attempts (without
tombstone) won't survive — they'll need to leave once more after
the upgrade. The "rejoining via invitation clears the tombstone"
path means this isn't a one-way door — explicit rejoin still works.

[AI-assisted - Claude]

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ignore)

Per the "don't accumulate follow-ups while fixing bugs" principle —
folding the small mechanical items from #249 into this PR rather than
deferring:

* **#2 / Skeptical M4**: `Rooms::leave_room` now also retains
  `migrated_rooms` to drop any pending upgrade-pointer entry for the
  left room. Previously, if a room had been recorded for upgrade and
  the user then left, the upgrade pointer would still be sent.

* **#3 / Skeptical L1**: `PartialEq for Rooms` now compares
  `removed_rooms` too. Two `Rooms` differing only in tombstones used
  to compare equal — a latent footgun if any code uses equality to
  short-circuit a save.

* **#6 / Skeptical L3**: `.gitignore` excludes `**/.syncthing.*.tmp`
  so syncthing's in-flight transfer markers don't show up as
  untracked files.

Three items remain in #249, all genuinely deferred:

* **#1 Timestamped tombstones (Codex P2)**: real but requires custom
  serde for backward compat with the HashSet we're shipping. Scenario
  is rare (River doesn't have automatic multi-device sync; single
  delegate writer) and user-recoverable (leave again). Not paid for.
* **#4 `removed_rooms` GC/TTL**: hypothetical for heavy users; defer
  until there's evidence.
* **#5 Cross-version divergence**: mostly moots itself as users
  upgrade. Schema-versioning is an architectural change for later.

17/17 `room_data::tests` still pass.

[AI-assisted - Claude]

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>