Measure where a re-score pass actually goes, before optimising the reads

[ryanbr]

Pricing the "make the pass cheaper" option on #1538 got as far as static analysis can, then hit a wall. Instrumentation only — no behaviour change, no scoring change.

What the static analysis settled

Each day reads a 54-hour night window (dayStart − 30h → dayStart + 24h) on a 24-hour stride. Consecutive windows overlap by 30 hours, so every row is materialised about 2.25× per pass:

Window-hours read per pass	1,134
Distinct hours in the span	534
Redundant	53%
HR rows in one window @ 1 Hz	194,400 against a limit: 200_000 — 97% of cap

Nine windowed store reads per day survive. The day-window reads (dayHr / daySteps / dayGrav) are already sliced out of the night lists by #997/#1346, so that part of the work is done and shouldn't be re-done.

What it could not settle

Whether reads or analyzeDay dominate. The pass has only ever timed itself end to end (re-score: done … in N ms), so the ~22.6 s per night is an undifferentiated number. That single ratio decides whether narrowing the windows is worth building, and no amount of reading the code answers it.

The design this would unlock, and the one it rules out

The obvious fix does not work: reading the whole 21-day span once and slicing would hold ~1.8M HR rows in memory, and OOM on big-import libraries is a known failure of this exact path.

A sliding window would. The loop already walks newest→oldest, so it could read only the incremental 24 hours per step and drop the tail — same peak memory as today, 2.25× fewer rows materialised. That is a real design, but it is only worth building if reads actually dominate.

What this PR adds

One diagnostic line per pass, on both platforms, byte-identical:

analyzeRecent cost prep=12345ms score=6789ms

• prep brackets the nine windowed store reads plus the session matching between them.
• score brackets analyzeDay.

They deliberately do not sum to the pass total — pass 2, the baseline folds and the reconciliation all sit outside this loop — so the line is to be read as a ratio, which is the only thing the question needs. A day skipped for too few HR samples still counts its prep, or the tally would under-report exactly the sparse-history installs where reads dominate most.

This is the instrument-first pattern the repo already uses for questions it cannot answer from a desk — #1344 for the pass duration, #688 for the REM funnel.

How to read the result

• prep ≫ score → build the sliding window; the ceiling is ~53% of read time.
• score ≫ prep → narrowing windows is a dead end whatever the row counts suggest, and the persistent day cache is the only remaining lever.

Verification

Android 4,229 tests, 0 failures (--no-build-cache --rerun-tasks), matching main. Doc lint clean. app-build dispatched for the app-target Swift.

Not run on hardware — which is the entire point: this exists so a real device can answer a question a desk cannot. Partial work on #1538; that issue stays open.

[ryanbr]

Re-reviewed the code. No changes — the timer accounting verified complete, and two limitations recorded rather than papered over.

Accounting is closed on both platforms

The risk in an instrument like this is a path that starts a timer and never accounts for it, which silently under-reports one phase and skews the very ratio the PR exists to produce. Traced every exit:

	Swift	Kotlin
Cache-hit continue	line 833 — before tPrep0 (843)	line 675 — before tPrep0 (682)
Only other continue in range	850, the ≥200-sample guard — accounted	694, the MIN_HR_SAMPLES guard — accounted
score add	immediately after analyzeDay's closing paren	same

So a reused day contributes nothing to either phase (it does no reads and no scoring — correct), a day skipped for too few samples contributes its read time but no score time (correct — it paid for the read), and no day can start a timer that goes unrecorded. analyzeDay is a single expression with the add on the next line, so nothing can exit between capture and accounting.

The emitted strings are byte-identical across platforms, both truncating rather than rounding.

Two limitations, deliberately not changed

Different clock sources. Kotlin uses System.nanoTime() (monotonic); Swift uses Date() (wall clock), matching how the pass total has measured itself since #1344. An NTP step mid-pass would corrupt the Swift figure. The exposure is pre-existing and consistent within the file, and switching Swift to a monotonic clock is a change I cannot compile in this environment — so it is flagged rather than made. Say the word if you would rather have it monotonic before this runs on a device.

No denominator on the cost line. prep=…ms score=…ms carries no day count of its own. The ratio is what the decision needs, and the dayCache reused=N/C … days=D line immediately above supplies counts — but two logs from different installs are not directly comparable on magnitude alone.

Neither is worth uncompiled churn while the PR is green and waiting on a hardware measurement.

Unchanged from before

Android CI built and tested this (build-and-test, 4m 8s), app-build compiled both Apple targets green, and the local suite ran 4,229/0. No CI was run for this review pass.