[ryanbr]

Refs #2315.

What

The Charge page could show two different HRV baselines at once: one at the top from the
engine, another on the "What shaped it" rows below it. Reported as 57 against 48 on the same
screen, with Coach offering a third number.

Three folds of the same history disagreed because one argument was missing:

TodayScoring.kt:41              foldHistory(..., hrvCfg, hrvBaselineEpoch)   headline
TodayScoring.kt:70              foldHistory(..., hrvCfg)                     driver rows
ChargeBreakdownWiring.swift:38  foldHistory(..., cfg:)                       the same, on Apple

noop.hrvBaselineEpoch is written by Settings, Recalibrate HRV baseline. The engine drops
every night dated before it; these folds kept the whole history. So the two agree until
somebody recalibrates, which is exactly why this survived review. The existing comment says
so out loud:

byte-identical to the engine's whole-history fold when no manual Recalibrate epoch is set,
the common case

It is the uncommon case that puts two numbers for one metric on one page.

chargeConfidenceTier had the same gap and is fixed alongside. That one reads
ScoreConfidence off the baseline, so a whole-history fold could badge a scored day from a
history the ring is not using.

Nobody else can be affected

Both entry points take hrvBaselineEpoch with a default of 0, and both foldHistory
overloads delegate to the plain fold at <= 0. That is read from the source, not assumed:

if (baselineEpoch <= 0.0) return foldHistory(values, cfg)

Each platform has a test asserting it: labels, baselines AND deltaPoints all identical when
the epoch is absent. A user who has never recalibrated sees byte-identical behaviour.

What this does not settle

Whether it resolves the report depends on whether that wearer has ever recalibrated, which is
still unanswered. If they have not, their epoch was already 0, these folds were already
identical, and their 57 against 48 has a different cause. The question is on the issue.

The fix stands either way: the rows have to score against the baseline the headline scores
against, whatever caused this particular report.

Coach's number is a separate matter, not touched here. It computes its own plain 30-day mean
with no winsorization and none of the seed or trust gating (CoachSuggestions.kt:94,
CoachSuggestions.swift:97), so it will differ from both of the above for anyone with one
unusual night. Worth its own change, since routing it through Baselines is a behaviour
decision rather than a correctness one.

Tests

Three Kotlin, two Swift. The epoch fold discards pre-recalibration nights and lands on a
different baseline; an absent epoch changes nothing; and the confidence tier moves with the
same epoch, using a post-recalibration history that is still under the four-night seed gate
while the whole-history fold looks fully trusted.

Verification

• Android: 6256 tests, 0 failures, forced full run, result XML checked fresh against the clock
• python3 Tools/doc_comment_lint.py: clean
• The Swift half is app-target and compiles in no local package, so it is swiftc -parse
  checked here and first type-checked by CI's build (Strand, macOS), which also runs the
  ChargeBreakdownWiringTests additions.