Mobile: keep messages and recent threads available through connection drops #25973

The implementation is up for review in #26013.

🤖 Generated by an LLM on behalf of Tomasz Tórz.

Data on a narrower version of this, in case the full proposal is too big a first step: prefetch only what the mobile home list shows — the top six threads, then up to 12 rows on screen after a scroll settles — one at a time, each loaded again when its row changes (at most once a minute), plus starting the load on touch-down.

iOS simulator, T3 server on a copy of a real 6 GB database, 5G (120 ms RTT, 10/5 Mbps) through a shaping proxy, server CPU limited to 10 %: opening a never-opened thread went from 1.13 s median (0.76–2.59, n=7) to 0.22 s (0.18–0.46, n=8). I have it as a branch and would open a PR only if a maintainer approves the direction and defaults (how many threads, whether to skip on cellular).

#26013 was closed because this discussion had no maintainer approval yet. I won't open another PR until a maintainer approves a direction here.

To make the decision smaller, the proposal splits into three parts that can be approved on their own:

1. Durable sends. A message sent during a connection gap is saved on the device before the composer clears, then delivered once and in order after the app reconnects or restarts. Each message keeps its commandId, so the server's existing receipts drop retries. This is the part that stops messages from being lost.
2. Offline threads. Thread snapshots are cached within a size budget, and recent threads are prefetched while connected. The narrower prefetch measured in the comment above (home-list rows only, one at a time) could replace the prefetch in my proposal.
3. Reconnect state. A small delayed chip with the queued count replaces the overlay, so the thread stays readable while offline.

The simulator recording in the opening post shows all three together on our fork. Part 1 is the one I'd send first.

Which of these, if any, would you approve for a PR? If it's only part 1, that PR would carry part 1 alone, with its own recording.