fix(activity): show Convert transactions in the feed

[bmc08gt]

Problem

A swap spans two mints, so the backend leaves payment_amount unset and carries both amounts in additional_metadata instead. ActivityFeedMessageMapper only ever read payment_amount, so every Convert was cached with a null amount, rate, and mint — which meant it matched no token's activity query and rendered blank in the global feed.

Changes

• Map multi-mint amounts from additional_metadata when payment_amount is absent.
• Attribute a Convert to both mints, so it shows on the source and destination token screens (new MintInvolvement, plus the metadata clause in observeRecentForMint).
• Render it like iOS: overlapping dual-token avatar, from-amount on top, -<fee> Fee beneath.
• Title the row with the two token names ("Moony → Jeffy") rather than the server's bare "Converted", falling back to the server text until both tokens resolve.

Cache repair (DB 28 → 29)

Rows cached before this can't be repaired in place — the amounts were never persisted — and they can't be re-fetched either, since fetchSinceLatest only ever walks forward from the newest cached id. The migration clears messages so the next sync falls into its descending re-seed and refetches from scratch; paging refills older history on demand. Same approach as the existing 1→2, 6→7, 7→8 and 9→10 migrations.

TransactionHistoryMigrationTest covers it, following the hand-rolled pattern in UserProfileMigrationTest: the feed is emptied, a neighbouring table survives, and it's a no-op on an already-empty feed.

The spec overrides onPostMigrate(SQLiteConnection) rather than the SupportSQLiteDatabase variant used by Migration22To23 — Room only calls the latter when the database is built without a driver, so a future .setDriver(...) would turn the delete into a silent no-op.

Silent data loss, found alongside

MessageDataSource.upsert no-oped when the per-user DB wasn't open yet, discarding a whole fetched page while ActivityFeedCoordinator still reported Synced. Because every sync path pages forward from the newest cached id, those notifications were never requested again.

It now fails loudly — matching observe(), which already errors on a missing DB. FeedRemoteMediator turns that into a retryable MediatorResult.Error, and the coordinator moved its write from onSuccess into mapCatching so Synced is only reported once the page has actually landed.

Note on missing history

Activity older than the backend's swap deploy is absent server-side — the widest query the client can issue (DESC, no paging token, pageSize=100) returns only post-deploy notifications, and all of them are persisted. That's expected data loss from the migration, not a client bug.