feat(update): tell sideloaded installs that a newer version exists

[dzianisv]

Why

AGE-110. Sentry release health, 30d to 2026-08-14:

version   users   share   sessions  share   gated
0.4.10     1858   64.0%     18489   61.6%   no
0.4.4       601   20.7%      4086   13.6%   no
0.4.12      291   10.0%      5231   17.4%   no
0.4.14        7    0.2%        17    0.1%   yes   <- the AGE-105 noise gate

The gate ships inside the binary, so its ceiling is the share of the base that installs it. Two channels are why that share is 0.2%:

1. Play lagged eight weeks (fixed in ci(play): publish release tags straight to production, not internal #177 - tag push now publishes to production).
2. Everything else has no update mechanism at all. No expo-updates, no releases check. A direct-APK install, a self-hosted F-Droid install without auto-update, or a third-party mirror install (APKCombo currently advertises v0.4.10 as its newest listing) cannot learn that a newer version exists. This PR is that half.

What changed

• src/lib/update-check-policy.ts - pure decision logic, runs under node --test with no RN, no network, no clock:
  • numeric version compare. A string compare orders 0.4.10 before 0.4.9, i.e. it would tell the single largest stale cohort in the install base that it is up to date. Covered by a test named after exactly that.
  • one check per 24h, and a lastCheckedAt in the future (restored backup, NTP correction) re-enables checking instead of locking it out
  • dismissal is remembered per version: "Not now" on 0.4.15 is never re-asked; 0.4.16 may ask once
  • last successful lookup is cached, so the affordance survives between checks instead of appearing only on the one launch that fetched
  • a failed fetch does not consume the interval - a device offline for a week checks on its next launch with network
• src/lib/update-check.ts - Android-only runtime wiring. One unauthenticated GET to the GitHub releases-latest endpoint per 24h, 8s timeout, drafts/prereleases ignored, never throws. GitHub releases (not expo-updates) because OTA JS cannot replace a native binary, and every non-Play channel is downstream of a GitHub release.
• src/components/UpdateBanner.tsx - one dismissible strip above the session list. Not a modal: a launch modal is the fastest way to get uninstalled, and this ships to the whole base. Renders nothing when there is no update, on iOS, or after dismissal.
• Settings Version row showed a hard-coded "1.0.0" for every build ever shipped. Now shows the real version, and 0.4.10 -> 0.4.14 with a tap-through when an update exists. It passes ignoreDismissed: true - a dismissal silences the interruption, not the place a user goes to check.
• en / zh-Hans strings; catalog-parity.test.ts stays green.

Privacy

One unauthenticated GET per 24h, no query params, no identifiers, no analytics event. GitHub sees an IP that already downloaded the APK from GitHub. On-device state is a timestamp plus two version strings (AsyncStorage, not SecureStore - nothing here is a credential, and the persisted-keys tripwire covers SecureStore writes, of which this adds none).

Verification

• node --test src/lib/update-check-policy.test.ts -> 19 pass
• npm test -> 300 pass
• npx tsc --noEmit -> clean

How we will know it worked

node scripts/release-uptake.mjs (#176) is the meter. This lands in the next release, so it can only move the cohort from that version forward - the v0.4.10 users get told once they are on any build that carries this. Play production automation (#177) is what moves the already-installed base.