feat(apple): hourly step import — per-hour iPhone steps with 90-day backfill (re-cut of #369)

[ryanbr]

Supersedes #369 by @vishk23, re-cut against current main. That branch was 385 commits behind and both of its migration slots had been taken since — GRDB v32-apple-step-hour collided with v32-rr-src-channel (main is at v37), and Room 26 collided with MIGRATION_25_26 (main is at 30). Migrations can't be rebased around, so this renumbers to the current tail rather than mutating shipped migrations.

What

The daily Apple Health import flattens iPhone steps to one appleDaily.steps total, so an hour the phone spent dead or sitting on a desk is invisible — the day just reads low. This adds an hourly table beside it:

• GRDB v38-apple-step-hour + Room MIGRATION_30_31 (@Database(version = 31), SCHEMA_VERSION = 31): additive CREATE TABLE only — appleStepHour(deviceId, ts, steps), PK (deviceId, ts) like every other per-sample table.
• Store API upsertAppleStepHours / appleStepHours, mirroring OuraRawStore, with an idempotent ON CONFLICT(deviceId, ts) upsert.
• HKStatisticsCollectionQuery at hour interval over the same sync window — same anchor (local midnight) and error handling as the existing daily collect() — plus a one-time 90-day backfill, flagged only after rows actually land (HealthKit returns EMPTY rather than an error when step access is denied, so gating on no-throw alone would burn the one-time widen on a deny-then-grant).
• appleStepHour registered in deviceScopedTables so Forget-device wipes it.
• Kotlin schema twin + migration test, and both byte-identical schema_oracle.json copies updated (roomVersion 31, v38 migration, table entry).

Fixes on top of the original

• Corrected what a missing hour means. Only hours with a step sample produce a row, so an absent hour is "no steps recorded" — a dead phone and a still hour look identical. Step data carries no separate "was recording" signal, so the doc now states a gap is evidence, not proof, and a consumer must not label it "phone off". (The original framing implied it showed exactly which hours were recorded.)
• Refreshed the stale renumbering commentary and the v27 store header left over from the earlier renumber.
• Added a test pinning SCHEMA_VERSION to the migration target so the two can't drift apart — the Record the app build in the backup, and beside a computed day #1410 failure mode.

Scope / caveats, stated plainly

Plumbing only — no UI reads the table yet (same precedent as #346, #895). The one irreversible part is the migration: once shipped you carry the table. Android carries the schema but no importer writes it (HealthKit has no Android analogue) — exactly the arrangement the older appleDaily table already has, and required to keep .noopbak byte-identical.

Data cost is small: 24 rows/day, so the 90-day backfill is ~2,160 rows and ongoing growth is ~9k rows/year.

Validation

• Full Android suite: 4,037 tests / 489 classes, 0 failures, including SchemaOracleTest (compares Room's KSP-generated schema against the oracle, so the hand-written table entry is verified against real Room output) and the 5 migration tests.
• Swift store + schema-oracle tests run in swift-packages CI (WhoopStore needs macOS).
• HealthKitBridge is app-target Swift with no default CI → app-build dispatched for this branch.

Credit: @vishk23 (original implementation, on-device verification of the 90-day backfill and the hour-by-hour overlay).