fix(chat): rebuild chat history after logout and gate the tip milestone on it

[bmc08gt]

An account that had already sent a tip was shown the new-user tutorial again after signing back in, with "Scan a Tip Card" unticked while the activity feed right below it listed the tip. The milestone is a read of chat history — ChatMessageDao.hasEverTipped looks for an outgoing message with verb TIPPED — and two things conspired to leave that history empty.

Logout wiped the cache

RealSessionController routed AuthState.LoggedOut into ChatCoordinator.reset(), which deleted every chat metadata, message, and member row. Nothing needed it to: FlipcashDatabase.init names the database file from the account entropy, so two accounts are already separated by sitting in different files — PersistenceProvider calls that file swap the protection, which is why it must not short-circuit on isOpen(). The activity feed has never wiped itself on logout for the same reason.

The wipe was load-bearing in one place: account deletion reaches logout() through deleteAndLogout. So rather than dropping it, ChatCoordinator now splits in two:

• teardown() — connections, jobs, in-memory state. What logout wants.
• clearCache() — the persisted rows. Called only from deleteAndLogout.

logoutAndSwitchAccount also routes through logout(), so account switching stops wiping chat history as a side effect.

One consequence worth a decision: chat text now survives logout on disk, and the Room database is not SQLCipher-encrypted. That is the same exposure the activity feed already carries, but it is a product call rather than mine.

Login could not rebuild what logout removed

performFeedSync decides which chats need catching up by asking two questions — does this chat have cached messages, and does its stored latestEventSequence trail the server's. It asked both after upserting the server's sequence onto every metadata row and each chat's lastMessage into the message table, so the first read was always true and the second always equal. Both branches were unreachable.

That left each chat holding the single message the feed carried. In the reported case the newest message in the Jeffy DM was the tip received back at 2:39, not the tip sent at 2:38, so the rehydrated message was inbound and hasEverTipped stayed false permanently. The fix snapshots both values before the writes.

The delta path had the same shape one level down: performDeltaSync re-read chat_metadata for its starting sequence, which by then held the value the sync had just written — asking the server for everything after its own latest event, which is always nothing. Event.DeltaSyncNeeded now carries the pre-sync sequence. The live gap-fill caller has no write in front of it and keeps reading the row.

The milestone read the cache before it was complete

Even with the two fixes above, the wallet drew its verdict on a cold cache. WalletViewModel.isAwaitingActivity covered the activity feed's sync state; nothing covered the chat cache, so a cold start still flashed "Scan a Tip Card" as outstanding until the history landed.

The feed sync cannot be that signal — it reports Synced once the conversation list is written, before the backfill it schedules has run, and that backfill is exactly what surfaces a tip older than a chat's last message. FeedSyncDelegate now sends a terminal Event.CatchUpComplete after the catch-up loop. Its events are a FIFO channel drained by one sequential collector in RealChatCoordinator, so every catch-up item ahead of the marker has completed its suspend call by the time it is routed; routing it sets ChatState.historyHydration to Hydrated. A failed sync moves Unknown to Unavailable instead — an unreachable server ends the wait rather than extending it — and never downgrades a hydration that already succeeded.

hasEverTipped() returns Flow<Boolean?> and withholds an answer while hydration is Unknown. A cached tip still answers immediately, since a TIPPED message in the cache is proof whatever the hydration state, which keeps the warm-cache path — now the normal one — off the round-trip. It re-subscribes to the Room query on the hydration change rather than combining the two flows: a combine emits the pre-backfill answer alongside the "hydrated" flip, which is the same flash in a narrower window.

WalletViewModel emits nothing while the milestone is null, so onboardingItems stays null and the tab holds its loading state. A held balance deliberately does not short-circuit this the way it does the activity-feed clause — it is evidence about money, not about tipping. The cost is a funded, never-tipped user with a cold cache waiting one chat round-trip before the tab draws.

Tests

New FeedSyncCatchUpTest (6), ChatCoordinatorTeardownTest (2), ChatHistoryHydrationTest (4), and WalletMilestoneGatingTest (2), plus two cases in AuthManagerTest pinning that logout leaves the cache and deleteAndLogout clears it. Both new suites are written against the specific way this bug hides. ChatHistoryHydrationTest asserts the whole emitted sequence, since the defect is a transient false on the way to true and the settled value is correct either way. The feed-sync harness models Room's write-then-read behaviour instead of using relaxed mocks, which answer false/0 regardless of what the sync wrote — the exact coupling under test.