fix(database): share one SQLite writer per owner and take write locks up front

[bmc08gt]

Bugsnag 6a4fde3, "Failed to persist conversation state [replace-feed]" with database is locked (code: 5). The event's log stream shows one cold launch running completeLogin five times for the same owner. Each call built a SessionContainer with its own Database, so several writer connections shared one SQLite file and their history syncs raced.

replaceConversationFeed runs a transaction that reads the doomed conversation ids before deleting them. Under BEGIN DEFERRED that first read takes a WAL snapshot, and when the delete then needs the write lock while another connection holds it, SQLite returns SQLITE_BUSY at once because upgrading a snapshot cannot wait. The busy handler never runs.

Changes:

• Container owns a new DatabaseStore that opens one Database per owner and hands the same instance back on every later request. It carries the whole open path that used to live in SessionAuthenticator.initializeDatabase — App Group resolution, the legacy-directory migration, and the schema-version check — so the only behavioural change is the cache. SessionAuthenticator.createSessionContainer now reads from the store, and initializeDatabase and its helpers are gone.
• replaceConversationFeed, persistMessages, and the shared Database.transaction helper run BEGIN IMMEDIATE, so a read-then-write transaction takes the write lock first and waits on the busy handler instead of failing.
• The two login-path logs move from debug to info with the attempt count in metadata, so the next release report shows how many times login ran.
• New Regression_6a4fde3 suite, four tests: the rival-writer reproduction holds an immediate transaction on a second connection to the same file for 200 ms and asserts the feed replacement lands; the other three cover the seconds-vs-milliseconds busyTimeout and the store's per-owner identity.

Supersedes #748. That branch was written against the pre-refactor tree and stopped rebasing once the App Group / FlipcashStore work in #753–#757 landed — Database.swift moved packages and the open path it edited no longer exists — so this is the same fix re-authored on top of it. That stack already fixed busyTimeout — SQLite.swift reads it in seconds, so the old 2000 armed a 33-minute wait — so the commit for it is dropped here and the suite asserts the value instead.

This matches what Android already does: FlipcashDatabase.init() is a synchronized singleton that returns the existing instance for the same database name, and Room's beginTransaction is BEGIN EXCLUSIVE, so its read-then-write DAO transactions never hit the deferred snapshot upgrade.

Two things this does not resolve. Why one launch called completeLogin five times is still unknown, which is what the info log is for. And logout() still does not tear down the previous SessionContainer, so an in-flight write from a stale container now lands on the shared live store rather than failing; that is pre-existing and left for a separate change.

Triage brief and plan are in .claude/plans/2026-09-09-bugsnag-6a4fde3*.md.