plans: profile unread count: picker refresh conditions, iOS resume race

plans/2026-08-29-profile-unread-count.md

@@ -7,7 +7,7 @@ The core seeds each profile's unread count in `getUsersInfo` (`Store/Profiles.hs
 - only mentions in a mentions-only group;
 - nothing in a muted chat.
 
-After the seed the client keeps the active profile's count up to date with its own deltas, and those used a different rule. The count drifted until the next seed (e.g. a profile switch, a restart, or opening the profile picker — always on iOS, on Android and desktop only when another field of the users differed):
+After the seed the client keeps the active profile's count up to date with its own deltas, and those used a different rule. The count drifted until the next seed (e.g. a profile switch, a restart, or opening the profile picker — always on iOS, on Android and desktop only when the users list differed in size, order, id, active flag, name or image):
 - A new item in a muted chat, or a non-mention in a mentions-only chat, added 1.
 - On Android and desktop, mark read, clear and single-item decrements subtracted every unread item, whatever the chat's setting. On iOS, mark read and clear followed the mentions-only setting but subtracted every unread item for muted chats, and single-item reads subtracted the raw delta. After a restart that pushed the count below zero for muted chats.
 - On Android and desktop `decreaseCounterInPrimaryContext` never decremented `unreadMentions`, so a mentions-only chat's mentions stayed unread in its stats.
@@ -25,7 +25,7 @@ Non-active profiles were already kept by the seed's rule (`ntfsEnabled`).
 - `Chat.userUnreadCount`: what a chat contributes by the seed's rule (`unreadCount` for All, `unreadMentions` for Mentions, 0 otherwise). iOS `totalUnreadCountForAllUsers` already computed this inline and now calls it.
 - These sites read the contribution before and after, and the count moves by the difference (`changeUserUnreadCounter`): new item, mark read, clear, single-item decrement, chat removal, a settings change made in the app (mute/unmute), and the iOS "keep conversation" re-add. For a settings change both platforms read the listed chat, with the settings it had before the API call, because an item event processed during the call can already carry the new settings. On iOS `updateChatSettings` reads `ChatModel.getChat`, not the chat object it was passed, which is stale after a resume rebuilds the list; the iOS "keep conversation" re-add likewise takes the listed chat's stats.
 - `decreaseCounterInPrimaryContext` also decrements `unreadMentions` when the item was a mention.
-- The counts are re-read from the core with the chat list: on resume (Android and iOS) and after setting a chat item TTL (the active profile). Reading users is best effort, so a failure keeps the chats already fetched. The Kotlin picker now also applies count-only changes when it re-reads users; before, it replaced them only when another field differed (e.g. with hidden profiles), while iOS always did.
+- The counts are re-read from the core with the chat list: on resume (Android and iOS) and after setting a chat item TTL (the active profile). Reading users is best effort, so a failure keeps the chats already fetched. The Kotlin picker now also applies count-only changes when it re-reads users; before, it replaced them only when the list differed in size, order, id, active flag, name or image (e.g. with hidden profiles), while iOS always did.
 - Opening a chat on Android and desktop replaces its stats with the server's. When the chat was already listed and its contribution drops, the count drops by the difference; it never moves up here, because a chat from outside the 5000-chat window can be listed with empty stats while the seed already counted its unread items. A chat the load adds comes with the server's stats, which the seed already counted. A content-filtered initial load of a group returns zero stats when no unread item matches the filter (otherwise the full counts), so a load with a content filter does not move the count (`statsFiltered`). A search never reaches this path: the core rejects initial pagination with a search. iOS keeps the listed chat's stats on load, so it has nothing to move.
 
 ## Alternatives considered
@@ -46,6 +46,7 @@ Each is a separate change:
 - If a new item arrives between a chat load's query and its stats replacement on Android and desktop, the downward move can drop the count below the database until the next seed.
 - A settings change computes its move from the chat's settings when the call started. If another settings call on the same chat, a chat load or a reseed applies the new setting while the call is in flight, the count moves twice and ends off until the next seed.
 - iOS unread tag counts on a settings change still read the chat after the call, so they miss the change when an event already applied the new setting (pre-existing; the Kotlin side now uses the same before/after pair as the count).
+- iOS: an item's delta waits about a second in `unreadCollector`, which a resume refresh does not clear, so an item that arrives just before the refresh is counted by both the refreshed count and the queued delta, until the next seed.
 - "Mark unread" is not counted, by design: the seed does not count it either.
 - The Unread filter change (groups with unread support chats) will be a separate PR stacked on this one.