feat(nse): extension crash reporting, a WAL checkpoint, and on-device push hooks

[bmc08gt]

Groundwork for moving the SQLite store into group.com.flipcash.shared, split out so the App Group move lands on top of it rather than tangled into it. Each piece stands on its own; none of them change app behaviour.

Crash reporting for the notification service extension

The extension is a separate process and ErrorReporting lives in the app target, so today an NSE crash produces no report at all. ExtensionReporting starts Bugsnag once per extension process and tags events with process = notification-service, which is what makes them separable from the app's in the dashboard — both report under the same app id otherwise.

It is deliberately not hoisted into FlipcashCore. That would put Bugsnag into the dependency graph of the core package, including its macOS vector test plans.

Three call sites: the start and a didReceive breadcrumb at the top of the entry point, and a capture on the prefetch failure path, which currently swallows its error.

One limit worth stating, because silence here will otherwise read as health: a jetsam kill for exceeding the extension's memory limit terminates the process without an exception, so it produces no report. Extension memory headroom still has to be measured.

Database.checkpoint()

PRAGMA wal_checkpoint(TRUNCATE). TRUNCATE rather than PASSIVE because a passive checkpoint gives up silently when any reader is mid-transaction, which is precisely the case that leaves the WAL growing without bound. This one blocks up to busyTimeout and throws when it cannot finish.

It has no production caller yet — it gains one in the next PR, which wires close() to app lifecycle. Landing the pragma and its tests separately keeps that PR to the connection-lifecycle change, which is the part with real blast radius.

Device harness hooks

Three CommandLine.arguments gates in AppDelegate, plus PushController.copyTokenToPasteboard(). None can run for a user.

They are here because 0xdead10cc — the watchdog kill for holding a lock on shared storage while suspended — is the one risk in this workstream a simulator cannot reproduce. The App Group move therefore has to be re-checked on hardware, and the spike that cleared it was bounded by one device and one OS, so that is standing advice rather than a one-off.

On a physical device there is otherwise no way to set a beta flag (Maestro does not support physical iOS devices, and devicectl cannot inject touches), no way to reach .authorized (the notification prompt is reachable only from onboarding or a money flow, so a device that skipped onboarding cannot get there, and without it there is no APNs token and no way to push the extension at all), and no way to read the FCM token (the log redactor strips it, correctly).

--beta-flags= sits outside the --ui-testing branch on purpose: that flag also suppresses keychain auto-login, so a launch that set flags through it would have no session and no open database.