feat(notifications): write prefetched messages into the shared store

[bmc08gt]

Last of the five. The extension already fetches five messages on every chat push; they went only into NotificationPreviewCache, a JSON side-car the content extension reads and the app never opens. The app then refetched the same messages on launch. This gives that fetch a destination the app reads, and adds a second source that needs no fetch at all.

Stacked on #755. Review that one first.

What changed

NotificationService.cachePreview now also calls Database.persistMessages with the messages it just fetched. The side-car is unchanged — it is the content extension's only source, so this is a second destination, not a replacement.

ExtensionStore.perform is the whole cycle an extension has to use around a store in shared storage: open, write, checkpoint, close, inside performExpiringActivity. Holding the App Group store's lock while the process is suspended is the case iOS kills with 0xdead10cc; the expiring-activity assertion is what keeps the process alive until close() returns. The close() it calls landed in #753.

It refuses to run in two cases, and both are guards rather than niceties:

• No store file. Database.init creates one if it is missing. An empty store at the shared path reads to StoreMigration as a finished migration, and the app would then delete the legacy store. That is data loss out of a push arriving before the first migrated launch.
• A recorded schema version that is not this build's. Both directions no-op. Deleting and rebuilding a store from sync is the app's job; an extension with 30 seconds should not start it.

Everything else — a busy lock, a thrown write, an expired assertion — returns without a store left open, because close() is in a defer.

The embedded message

Bumping flipcash2-client-protocol to 0.5.0 brings push.v1.ChatMetadata.message: the message the push is notifying about, carried inline. That matters because every store row until now came from a network fetch, so a push arriving with no usable connection wrote nothing — the case where a warm store is worth most, since the app is about to cold-start too.

NotificationPayload.chatMessage decodes it through the existing ConversationMessage.init?(_:), so content this client can't draw is dropped the way it is everywhere else rather than becoming an empty row. It merges with the fetched transcript instead of being written separately: the two agree on eventSequence for the message they share, and one store cycle per push keeps the cost at one checkpoint. The fetched copy wins a tie, being the one the server rendered most recently.

The two paths that previously wrote nothing — an empty fetch and a transport failure — now write the embedded message when the push carried one.

0.5.0 also deprecates ChatMetadata.sending_user_id in favour of reading the sender off the embedded message. Nothing here reads it yet; the substitution path still works off titleSubstitutions.

Schema version moved out of Info.plist

SQLiteVersion was an Info.plist integer the app read through InfoPlist.value(for:). The extension needs the same number to make the version check above, and it cannot read the app's Info.plist — separate bundles. It is now Database.schemaVersion in FlipcashStore, which both targets link, so they cannot disagree. The plist key is removed rather than left behind for someone to bump.

Two calls worth disagreeing with

The cursor is not advanced. persistMessages(_:cursor:conversationID:) is called with cursor: 0. The extension fetched a bounded five-message preview, not a delta; advancing the catch-up cursor past it would make the next sync treat the gap as already covered.

No conversation row is synthesized. A push for a conversation the app has never seen writes the messages and nothing else, so the conversation stays absent from the feed until sync introduces it. Inventing a row from what a push carries is a bigger change than this PR, and it would be guessing at fields sync knows.

The write runs before deliver(). It costs the banner a few milliseconds plus roughly 100 ms of checkpoint. After deliver() there is nothing keeping the process alive, which is the wrong place to be mid-write.

Tests

ExtensionStoreTests covers the guards and the cycle: a missing store creates nothing, an older and a newer recorded schema are both skipped, writes are visible to a subsequent app-side read, the cursor stays where it was, repeated deliveries merge, a stale delivery loses to a newer sequence, the -wal is 0 bytes after the call, a throwing body still closes, and a held BEGIN EXCLUSIVE produces .busy rather than a hang.

NotificationPayloadTests covers the new accessor: the embedded message maps through, its eventSequence survives (which is what lets it merge rather than duplicate), and it returns nil for a server that omits the field, a non-chat category, and content the client can't represent.