perf(android): skip the redundant per-day store re-read in analyzeRecent (#997 twin)

[ryanbr]

Ports the Swift #997 per-day read-skip to Android, closing a real parity gap and cutting per-pass I/O on the exact path behind the #1005 background-drain reports.

The gap

During analyzeRecent's per-day scan, Swift avoids re-reading each calendar day's HR/steps/gravity from the store: for a past day the night window it already read — [dayStart − 30h, nextMidnight] — spans the whole calendar day, so it derives the day streams by filtering the in-memory night lists (AnalyticsEngine.daySliceFromNight, #997). Android had no twin and re-read all three streams from the store per day:

val dayHr   = repo.hrSamples(owner, dayMidnight, dayEnd, STREAM_LIMIT)
val daySteps = repo.stepSamples(owner, dayMidnight, dayEnd, STREAM_LIMIT)
val dayGrav  = repo.gravitySamples(owner, dayMidnight, dayEnd, STREAM_LIMIT)

That's ~3 reads × ~20 past days = ~60 redundant store reads per pass — including the big ~86k-row HR reads — and the pass runs ~every 15 min while a strap is connected, plus on every offload. (The Swift doc/test even claimed a Kotlin twin existed; it didn't. Now it does.)

The change

• Add AnalyticsEngine.daySliceFromNight to the Kotlin AnalyticsEngine (next to offWristIntervals, mirroring where the Swift twin lives), a pure generic:

  if (dayLo < nightLo || dayHi > nightHi || night.size >= limit) return null
  return night.filter { ts(it) in dayLo..dayHi }

• Wire the three day-read sites to slice-then-fall-back: daySliceFromNight(...) ?: repo.X(...).
• Correct the Swift AnalyticsEngine.swift + DaySliceFromNightTests.swift comments that referenced a nonexistent IntelligenceEngine.daySliceFromNight → AnalyticsEngine.daySliceFromNight.

Why it's safe (byte-identical, can only skip work)

The guard declines to a direct read whenever the shortcut would be unsafe:

• TODAY — its calendar day runs past the 18 h night cap (dayHi > nightHi) → direct read (so an afternoon/evening workout is still seen same-day).
• A limit-truncated night read (night.size >= limit) — ORDER BY ts ASC LIMIT could have dropped the late rows exactly where the day sits → direct read.
• A DST-shifted day bound simply falls outside the window and declines.

When it does slice, it's byte-identical to the direct read: same owner, same inclusive [dayLo, dayHi] bounds (matching the DAO's ts >= from AND ts <= to), same ts-ASC order (filtering preserves it), and the HR COALESCE union (measured ∪ v26 PPG, #172/#219) dedups on a range-independent ts anti-join, so coalescing-then-filtering equals coalescing over the day range.

Verification

• compileFullDebugKotlin — clean.
• New AnalyticsEngineDaySliceTest (twin of the macOS DaySliceFromNightTests, same bounds fixture: past-day slice equals the in-range filter, TODAY/DST/truncated-limit decline, inclusive both ends) — green.
• Every analyzeRecent-exercising suite green, incl. day-owner, edit-scope, and repeat-repro — the ones that would catch a wrong-day attribution if the slice ever diverged from the direct read.
• Swift side is comment-only (the SleepPSG: sync RecipeConfig.shipped with #987's awake row (main is red) #997 logic already shipped there), so no app-build gate needed; swift-packages covers StrandAnalytics.

Both platforms now share the same read-skip; no behaviour or stored-data change on either.