data: stop silently dropping TDLib updates

[tdrkDev]

(c) Claude Opus 5 & Claude Fable 5

Updates were fanned out through a single MutableSharedFlow(replay = 3, extraBufferCapacity = 64, DROP_OLDEST) with 18 independent subscriptions on it. Several of those collectors perform suspending Room writes or TDLib requests inline, so they are orders of magnitude slower than the arrival rate. Once any subscriber falls more than 67 values behind, DROP_OLDEST fast-forwards it past everything it had not consumed; tryEmit still returns true and nothing is logged, so the loss is invisible to both producer and consumer.

The flow was never blocking TDLib - tryEmit with a non-SUSPEND overflow policy cannot fail or suspend - it was hiding the fact that downstream could not keep up. Losing these updates is not recoverable: updateNewChat is the only introduction of a chat object, and after it is missed every later cache.updateChat for that chat is a silent no-op, so the chat is blackholed permanently. Under a 3000 updates/s burst the persisted mirror ended up with 139 of 300 chats and 121 of 300 correct titles.

Introduce TdUpdatePipeline, which offers two explicit contracts:

• lane(): lossless and strictly ordered. Private unbounded queue, private worker, per-update exception isolation. For consumers that write to Room, mutate ChatCache, or issue TDLib requests.
• updates: lossy by design, DROP_OLDEST. For consumers that render state they can re-read.

Ingestion from the TDLib callback thread is one non-suspending enqueue; a dedicated pump thread does the fan-out. That thread also delivers every query result, so it must stay O(1): fanning out on it directly measured 38us/update with eight lanes attached, against a ~8us total budget, because each trySend has to resume a parked receiver. Through the pump it is 6-9ns and flat in the number of lanes.

There is deliberately no bounded lane. Channel(capacity, DROP_OLDEST) does not report what it discarded, which is the defect being fixed.

Migrated to lanes: messages, chat-list, users, notifications, files and notification-settings. Story, TelegramLink, Sponsor, Sticker, AttachMenuBot, Privacy, ConnectionManager and Auth stay on the observation flow - cheap handlers over state that is re-fetched or independently defended.

The users lane carries updateUser and updateUserStatus together; status is handed to the existing LatestByKeyBatcher, which conflates per user id, so the lane stays cheap without losing a user's presence entirely.

Also replaces MessageRepositoryImpl's .catch { Log.e("CRITICAL: Update loop died") }, which ended the subscription permanently on the first exception, and moves TdMessageRemoteDataSource's remaining rendezvous MutableSharedFlow() declarations onto OrderedEventFlow - with the default arguments every emit parked until all subscribers had taken the value, piling up ~5200 coroutines under load. Upload progress keeps a bounded DROP_OLDEST buffer instead, since progress ticks are conflatable.

Verified: 300/300 chats and titles persisted under the same burst, ordering preserved, callback thread cost per update 4.84us -> 2.25us, request results delivered in the window 165 -> 269. :data, :presentation and :app compile; 129 data unit tests pass, including 8 new TdUpdatePipeline contract tests.

Not addressed here: the loss-critical repositories are still lazily constructed, so their lanes register late and miss anything TDLib sent beforehand. Lanes fix loss under load, not late registration.