Refuse to open a journal on a build without SQLCipher

[Jberma23]

What this does

Adds the runtime guard half of #130: the app now refuses to open the journal on a build that has no SQLCipher, instead of silently writing a plaintext one.

PRAGMA key cannot tell you whether SQLCipher is present. SQLite ignores pragmas it does not recognise rather than erroring, so on a stock build the key statement is accepted and does nothing, the schema read after it succeeds against a plaintext file, and the app writes an unencrypted medical journal with no error, no warning, and nothing observable that distinguishes it from the encrypted case. Verified against stock SQLite:

PRAGMA key on plain SQLite: ACCEPTED SILENTLY (no error)
sqlite_master probe still works: {"c":0}
PRAGMA cipher_version -> null

That build is easy to be running. useSQLCipher is applied by a config plugin at prebuild, so Expo Go has never had it, and neither has a stale ios/ or android/ directory generated before the flag was set — and until #129 lands the README still tells contributors to use Expo Go.

PRAGMA cipher_version returns a version string on a SQLCipher build and no row on stock SQLite, which makes it the one cheap way to tell them apart. It asks the library rather than the database, so it is safe ahead of the key — and asking first means a build that cannot encrypt fails against an empty file rather than filling one with plaintext. The error names the remedy (npx expo prebuild + a development build), since whoever hits it is the person who most needs to read it.

0017 refuses an unencrypted fallback on web for exactly this reason: a silent downgrade makes the privacy promise untrue in the way nobody notices until it matters. This applies the same rule to a build that lost SQLCipher, and reports it as SQLCipherUnavailableError rather than a generic open failure — the problem is the binary, not the database, and "could not open the journal database" would send someone looking in the wrong place.

Issue

Addresses #130

Not closing it. #130 has two halves and this is only one: whether a SQLCipher build can read an unkeyed plaintext catalog.db still needs a device, and is untouched here.

Testing

• Covered by tests

cd mobile && npm test → 11 suites, 114 tests, all pass (109 before). npx tsc --noEmit and npm run lint clean, on Node 22.20.0.

Five new tests, mutation-checked: commenting out the assertSQLCipher call fails all five and nothing else, so they are genuinely load-bearing rather than passing by coincidence. They cover the refusal itself, that the check happens before PRAGMA key so nothing is written to the file, that the message names the remedy, that the handle is closed, and that it is not reported as a generic DatabaseUnavailableError.

Two existing ordering assertions became index-based casualties of inserting a statement — they now locate PRAGMA key rather than assuming position 0, which is what they actually meant.

Cannot be tested here: that a real SQLCipher build returns a version string. That is the device half of #130.

Notes for review

• Stacked on Address #128 review: unopenable journals, repository binding, and the node:sqlite guard #138, not on feature/encrypted-storage-unlock-foundation directly, and targeted at Address #128 review: unopenable journals, repository binding, and the node:sqlite guard #138's branch. Both PRs edit the same region of open(), so basing this on Paul's branch would have guaranteed a conflict. Merge Address #128 review: unopenable journals, repository binding, and the node:sqlite guard #138 first and this retargets cleanly; the diff here shows only its own commit.
• Ordering choice worth a look. getOrCreateDatabaseKey() still runs before openDatabaseAsync, so on a broken build a key is minted and stored before the guard fires. That is harmless — we throw before anything writes, so the file stays zero-length and a later correct build keys it normally — but the alternative was reordering, which breaks the existing "does not open the database if the key cannot be read" test. Happy to swap if reviewers prefer.