[ryanbr]

Refs #1801. Wires hrOnlySessions into the day scan for a strap with no motion — and fixes a real
flaw in the spine merged in #1805 that writing the tests exposed.

The anchor was wrong, by arithmetic

hrOnlySleepRuns took its band from hrBaseline, the window median, on the reasoning that
reusing the motion path's definition was parity. That was wrong, and not as a matter of tuning:

A median splits the samples in half by definition, so a band of median × 1.05 admits strictly
more than half of any window, whatever the data.

Measured on a realistic 24 h — 16 h awake at 74–96, 8 h night at 59–70 — it called 14.4 hours
sleep against a truth of 8.

hrSleepBandMult is correct where it was designed to be used: a confirmation gate on a run
gravity stillness already found, where permissiveness is deliberate. A confirmation threshold and a
detection threshold are not the same instrument, and #1805's doc argued they were.

Now anchored on hrOnlyBaseline — the tenth percentile, nearest rank — which sits in the
night's trough and cannot admit half a window however the day is shaped.

Why p10 × 1.05

Swept anchor × multiplier against windows with known truth, taking the conservative corner
because the failure directions are not symmetric: over-detection puts a wrong Rest on screen,
under-detection leaves "No data", which is the state this feature improves on.

anchor	mult	field-like 24 h	54 h, two nights	flat sleeper
median (#1805)	1.05	14.4 / 8	—	—
p10	1.05	8.1 / 8	8.7 / 16	5.9 / 8
p05	1.10	9.5 / 8	8.7 / 16	8.0 / 8
p15	1.05	10.8 / 8	11.7 / 16	8.0 / 8

hrOnlyBandMult is a separate constant from hrSleepBandMult — equal today, but a detector's
tolerance and a confirmation gate's have no business moving together.

Merge the runs, or the night never survives

A run boundary is a threshold crossing, and a sleeping heart rate oscillates across the band all
night. Without mergePeriods the spine returned the night's minutes correctly but shredded into
sub-mergeMin fragments, every one of which then failed the minimum-duration gate — 8 h of
detected sleep yielding zero sessions. The motion path calls mergePeriods for exactly this
reason; now so does this one.

Display-only, enforced structurally

An HR-only night carries null restingHR and avgHRV, and the AnalyticsEngine enrichment
that would refill them now skips it. Those two values are what Charge and the baselines fold in, and
a baseline is the one thing a false positive cannot be unwound from. Withholding them is structural;
a downstream filter would be one forgotten call site from failing open.

The Swift enrichment also now names hrOnly when it rebuilds the struct — unlike Kotlin's copy,
that rebuild drops a new field by default.

A WHOOP 4.0 is untouched

Reported working, and it must stay that way: the fallback sits behind grav.size < 2 and only
when the device persisted no hypnogram of its own, so a strap that banks motion keeps the motion
spine. A working detector must not be replaced by a weaker one. Pinned by a source-reading test.

Two comments this change falsified, corrected

• the no-motion diagnostic no longer claims the stager has no HR-only fallback;
• the Apple day-cache no longer justifies itself on "a WHOOP always streams gravity" (it now notes
  the HR-only providedSleep derives from the very HR the cache key already fingerprints).

Verification

• 18 Kotlin tests, 0 failures across the three HR-only classes; result XML checked for real
  counts, not a zero-match filter.
• Swift twins compile; the package test binary cannot link GRDB's sqlite3 on Linux, so CI runs
  them for real.
• compileFullDebugKotlin, swift build, doc_comment_lint, i18n_audit --ci all clean.
• Strand/Data/IntelligenceEngine.swift is app-target Swift that no default CI job builds —
  wants an app-build dispatch before merge.
• Not validated against a real night. Every number above comes from synthetic sinusoids with
  known truth. They establish how much of a window the detector claims; they cannot establish that
  the staging inside a claimed night is accurate.