fix(chat): settle the chats list in one update after launch

[bmc08gt]

On cold launch the chats list painted from cache and then kept changing: rows reordered, previews updated one at a time, and unread counts popped in. The list should be current the first time it settles, with only new events changing it after that, and launch must not get slower.

Why it churned

• start() and the .active hook in AppDelegate each ran loadFeed(). .active fires on cold launch too, so every launch made two full feed loads and two backfill passes.
• The contact DM, tip DM and group feeds each applied on their own and re-sorted the list.
• Backfill rewrote previews per chat after the list was showing.
• resolveUnreadCount ran a GetMessage per row from the row's .task.

What changes

• The cached list still paints immediately and is interactive.
• loadFeed() shares one in-flight task, so launch, foreground and reconnect make one fetch per feed type.
• Once all three feeds return, they apply in one non-animated update, with unread counts resolved at width 4 inside it. The wait is capped at 2s for a slow feed and 1.5s for unread (FeedReconcileTiming.launch); past a cap, whatever has landed is applied. The reconcile does not wait on backfill. The feed carries the read pointer's message id but not its unreadSeq, so counts can't be computed locally.
• Backfill runs after the reconcile through BackfillQueue, and an opened chat jumps the queue. The open chat shows its cached transcript at once and shows the placeholder only when it is empty.
• Writes are newer-wins. The store keeps a stored lastMessage and lastActivity when a feed copy is older, and advanceLastActivity ignores a date that isn't later. A test caught a delayed feed response rolling back a row that a stream event had just advanced.
• getConversations() takes the newer of a row's activity and its newest stored message. The notification extension persists message rows but never updates the conversation row, so a chat that got a push while the app was closed used to launch at its old position.
• An empty store keeps the existing progressive behaviour.

Tests: ChatListLaunchSyncTests (one reconcile with counts populated, no wait on backfill, older data doesn't move a row, empty store isn't held, one fetch per feed type), plus BackfillQueueTests, BoundedWaitTests, and store and database round-trip cases.

If the server deletes a chat's latest message, the row keeps its later activity and position, a side effect of the newer-wins rule.

Android counterpart: code-payments/code-android-app#1665.