Room list order is lost or reshuffled during chat-delegate migration #802

Reported in the Official room after today's two chat-delegate re-keys (#702, #797): the room list sometimes reorders.

Order is the user's drag order, Rooms.room_order, keyed by owner vk and persisted in the delegate's rooms_meta (ui/src/room_data.rs:1955-1973, 2020, 2132-2137). Rooms not in it are sorted by vk bytes (ordered_room_keys, :2810-2826). A room-contract re-key cannot change it; a chat-delegate migration can.

Causes

1. Transient snap (verified). The journaled walk merges recovered items into live ROOMS one at a time and fetches rooms_meta last (delegate_migration.rs:742-770). Until it arrives, rooms show in vk-byte order, then jump.
2. Lasting reorder from pruning (mechanism verified). Rooms::merge and apply_meta drop order entries for rooms not yet in map (room_data.rs:2776). A room that arrives later, e.g. from an older generation, is appended at the end. The next save persists that order.
3. Multi-tab overwrite (likely, not confirmed). reconcile_meta (chat_delegate.rs:8264-8295) writes room_order verbatim from the local tab. A tab with an empty or partial order can overwrite the restored one.

Fix

• Don't prune order entries for rooms that haven't arrived. ordered_room_keys already ignores missing rooms; prune only on leave.
• Apply the predecessor's order before or atomically with the rooms, or keep the "Migrating" state until it has merged.
• In reconcile_meta, don't let an empty order, or one from an incomplete room set, overwrite the stored order.

Related: the rail stops showing "Migrating your rooms…" once one room has loaded (room_list.rs:74-87). That makes a partly restored list look final; showing "restoring more rooms…" until the migration completes would help.

[AI-assisted - Claude]