Manually test the app on a simulator or device

[Jberma23]

Every claim about runtime UI behavior in this review is from static analysis only. Nothing has actually run the app on a simulator or device yet, worth doing before treating the accessibility/timeout/retry findings as fully confirmed in practice.

[PaulgSmith]

First run on real hardware: the app loaded and was usable on a physical Android phone via Expo Go, with the Rails API reachable and /api/v1/tasks serving the seeded records. Full CRUD (POST/PATCH/DELETE) was confirmed against the running API, and the Android bundle builds and serves (HTTP 200, ~8.9 MB).

Two caveats before treating this as closing the issue. First, the run was on a downgraded Expo SDK 54 branch, not main — Expo Go is SDK-locked, and an SDK 54 client refuses the SDK 57 manifest on main. Second, this only establishes that the app boots and talks to Rails; the accessibility (#87), request-timeout (#88) and retry/concurrency (#94) findings were not exercised and remain unconfirmed in practice. Android only, no iOS simulator.

[PaulgSmith]

Splitting one specific check out of this issue so it doesn't wait on a full manual QA pass: #130.

ADR 0016 (in #128) names this issue as "the natural place" for verifying that catalog.db — the public, deliberately unencrypted drug catalog from 0013 — can still be opened by a SQLCipher-linked build with no PRAGMA key set. Since useSQLCipher is build-wide rather than per-database, that situation arrives as soon as #128 merges.

Leaving this issue's own scope (the accessibility / timeout / retry findings from the static review) unchanged.