[ryanbr]

Problem

The steps calibration fits one coefficient from sixty days of strap motion, and it re-folded all
sixty on every analyzeRecent pass. Each day is a resolveDayOwner plus a gravitySamples
read capped at 200,000 rows, so a worn library pays millions of materialised rows per pass to
re-derive numbers that have not moved.

It also does not scale with the days being re-scored, since it always reads the same sixty
regardless, so a two-day pass can cost more than a twenty-one-day one. Identical on both platforms
(IntelligenceEngine.swift and IntelligenceEngine.kt); Swift hoists the reads off the main actor,
which fixes the jank but not the work, and Android has no hoist at all.

Change

StepsEstimateEngine.dayMotionIntensity is a pure fold over one day's gravity stream. Nothing else
reaches it: no profile field, no baseline, no toggle, no other stream. So a day is re-folded only
when that day's gravity witness moved.

• The witness is a new gravityFingerprint / gravityFingerprintWindow: COUNT(*) and
  COALESCE(MAX(ts), 0) over gravitySample for one device and window, on the same (deviceId, ts)
  index the read walks. A hit replaces a 200,000-row read with a single-row aggregate. Both columns
  come from ONE query on both platforms, so an insert cannot land between them and produce a key
  describing a state the day was never in.
• Deliberately narrower than dayStreamFingerprint, which also counts HR, R-R, respiration,
  SpO2, steps, skin temp and sleep state. An ordinary HR offload must not invalidate a motion volume
  it cannot have changed. It is not a new signal: this pair is exactly the g segment that
  fingerprint already computes for gravity, taken on its own.

Why count and newest-timestamp are enough

dayMotionIntensity sums the distance between CONSECUTIVE samples, so it depends on the set of
x/y/z values and on their order. Order is fixed by ORDER BY ts ASC in both reads. That leaves one
question: can a day's gravity change without moving either column? Only by rewriting a timestamp in
place, and nothing does. Gravity rows are insert-only (StreamStore / the offload path), the
timestamp heal exclusively DELETEs out-of-range rows, and an offload re-inserting an existing ts
is absorbed by the conflict key without changing a value. Insert moves the count, delete moves the
count. There is no in-place ts mutation to reorder a day underneath an unchanged witness.

• The cache is in-memory and per-process, beside the day-scan cache it mirrors, and needs no
  pass-config signature for the reason above. It never persists and never crosses the .noopbak
  boundary; a relaunch pays the full fold once. That is the intent: the cost being closed is the
  repeat within a process, where an offload storm fires passes back to back.
• A zero fold is cached too. Storing only the days that moved would leave every unworn gap
  re-reading its whole stream forever to rediscover that it is empty, which is most of the window on
  the sparse libraries this is worst for.

No behaviour change. motionByDay keeps the same m > 0 filter, so the calibration points, the
estimates and #1816's banked-motion flag are built from the same values as before. On Swift a
fingerprint that cannot be read bypasses the cache in both directions rather than keying on
(0, 0), which a genuinely empty day also produces; Kotlin's store surfaces no soft failure there,
so a throw aborts the pass exactly as the gravity read already did.

Why nobody saw it

#1538 added a per-phase cost line, but it brackets the day loop and is emitted the moment that loop
returns. Every phase after it was outside the tally, and the steps calibration runs about 700 lines
past the last number the pass printed. Swift now stamps each post-loop phase and renders them in
execution order beside re-score: done:

analyzeRecent postLoop total=31830ms dayReplay=10ms baselines=12ms score2=1100ms ... steps=28930ms ...

Android measures less, and says so. analyzeRecentOnCpu sits 210 bytes under the JaCoCo
method-size ratchet (55,490 against 55,700) and marking its phases costs about 467. That ratchet's
own note says to extract rather than raise it, and an extraction is a larger change than this one
should carry, so Android brackets the persist helper it can afford. The shared line takes an
explicit scope rather than reporting a postLoop total it never measured. Extending Android to
the rest of the post-loop needs that extraction first, and analyzeRecentOnCpu is untouched by this
PR.

Tests

• Mirrored StepsMotionCache and AnalysisPhaseTally suites on both platforms, pinned against the
  same literals, covering each input that must invalidate, the empty-day key, the owner boundary,
  execution order, the scope, and the clock-skew floor that keeps Swift's round-half-away-from-zero
  and Kotlin's round-half-up agreeing.
• IntelligenceEngineJacocoBudgetTest is repinned, not loosened: the two new diagnostics take
  their own positions in the ordered-operations guard, discriminated by argument expression because
  that guard masks string literals.
• A new runtime case measures the actual claim rather than asserting it: a second pass over
  unchanged days reads the witness for all sixty and the gravity stream for none.
• Android analytics + data suites: 2,488 tests, 0 failures. Swift package logic verified against a
  compiled standalone harness (no macOS available here); the Swift suites rest on CI.

Cost noted, not hidden

Owner resolution still runs per day. On the default single-device install it short-circuits without
a store read (#970), but a multi-strap install still pays sixty LIMIT-1 probes, exactly as before.
The first pass in a process still folds all sixty days.

The steps phase was identified by @DX23876.