feat(database): open the store on demand, close it on background

[bmc08gt]

Database opened a reader and a writer in init and held both until the process died. That is harmless while the app is the only thing on the file. It is the pattern iOS kills with 0xdead10cc once the store moves into the App Group and the notification service extension opens it too — so the store needs a close before it can move.

What changed

reader and writer are now throwing computed properties over optional storage guarded by an NSLock. close() checkpoints the write-ahead log and drops both connections; the next access reopens the store and reapplies the pragmas.

No production call site changed. All 121 reader./writer. uses in Database+*.swift and Schema.swift were already inside a try expression, which is why this shape won over a withWriter { } closure that would have rewritten every one of them. The eight uses in tests reading writer.totalChanges outside a try are the whole of the churn.

AppDelegate.scenePhaseChanged(.background) calls close() under a background-task assertion. .active has no counterpart on purpose: reopening is lazy, so an app that never comes back costs nothing and a close that lands at an awkward moment repairs itself on the next read.

journal_mode lives in the database header, but cache_size, foreign_keys and the busy timeout are per-connection and do not survive a close. The new tests assert them after a cycle rather than trusting the open path to have run.

The busy timeout was wrong by a factor of a thousand

Connection.busyTimeout is a Double of seconds that SQLite.swift multiplies by 1000 before calling sqlite3_busy_timeout, so busyTimeout = 2000 asked for 2000 seconds — next to a comment reading // 2 sec. It is the first commit on the branch, on its own.

Nothing has hit that ceiling while one process owns the store, which is why it has gone unnoticed. It stops being academic when the extension opens the same file: a 33-minute wait in a process that lives about thirty seconds is a hang.

What close() does not promise

Connection releases its handle from deinit and exposes no close(), so dropping the references only closes the store if nothing else is holding a connection. A caller partway through transaction(_:) keeps one alive until it returns, and the store closes when it does.

Under the app's own lifecycle that window is milliseconds at the background transition. It matters more with a second process on the file, and the extension's side of that is a later PR.

Stacked

Branches off feat/push-preload-groundwork (#751), which carries checkpoint(). Retarget to main once that merges.