feat(database): move the SQLite store into the App Group container

[bmc08gt]

The store lives in the app's private Application Support directory, which the notification service extension cannot open. It already prefetches five messages on every push and writes them into a JSON side-car that only the notification UI reads, because there is nowhere else to put them. This moves the store into group.com.flipcash.shared, which is what gives that fetch a destination the app reads on launch.

Paths in FlipcashCore, the move in the app target

StoreLocation replaces the four URL extensions on Database — dataStore, storeWAL, storeSHM, versionFile. It resolves the container, names the four files for an owner, and names them again in the pre-move directory. It is paths only, and never opens or moves anything: FlipcashCore has no SQLite dependency and this does not add one.

resolved() takes the container lookup as a parameter because containerURL(forSecurityApplicationGroupIdentifier:) is not consistent across platforms. On iOS it returns nil without the entitlement; on macOS, where this package's tests run, it returns a constructed path for any identifier. Passing a bogus group name therefore cannot reach the nil branch, and the seam is what makes the fallback testable.

That fallback keeps the store in Application Support and sets isShared to false. It means the entitlement is missing or the group is not provisioned — a build configuration problem — and the app works, with an extension that cannot see the store. SessionAuthenticator reports it, since FlipcashCore has no reporting channel.

The migration runs once, at the point the store opens

StoreMigration.migrateIfNeeded is called from initializeDatabase(owner:), before the version check and the open. Two ordering decisions carry it:

Checkpoint before moving. A store in WAL mode is up to three files, and rows that were committed but not yet folded in live only in the -wal. PRAGMA wal_checkpoint(TRUNCATE) first means one file moves and there is no window where the database and its log are in different directories.

Version file before database. The move is two moveItem calls and the process can die between them. In this order, a launch that dies after the first one finds no database at the destination, retries, and treats the already-moved version file as done. The reverse order leaves a store whose version is unreadable, which reads as 0 and triggers a full rebuild on next sync.

Failure recovery is scoped by whether the destination already held a store when the migration started. If it did, nothing at the destination is touched — the legacy files are leftovers to sweep, not data to adopt. If it did not, a partial move is cleared so the next launch starts from the legacy copy rather than a half-written one. Either way the outcome is reported and the app continues; a migration that cannot finish is not a reason to refuse to launch.

Opening the writer first is now load-bearing

A migrated store arrives as a lone .sqlite: the log was folded in and the -shm swept. A read-only connection to a WAL-mode database with no -shm beside it fails with unable to open database file, because it cannot create the shared-memory file it needs. Database.init opens its writer before its reader, so the writer creates it.

That ordering was incidental before and is not now. The extension in the next PR opens the same store from a second process and has to respect it.

Stacked

Branches off feat/database-connection-lifecycle (#753), which carries close(). Retarget once that and #751 merge.