[ryanbr]

Reported by @bartmuskala in #1662.

What was wrong

Tapping a graph printed a different number from the metric written beside it. Their screenshot shows a rounded headline over a one-decimal chart.

LineChart takes formatValue: ((Double) -> String)? = null. When it's null the scrub read-out falls back to formatLineValue, which rounds to an integer only if the value is within 0.05 of one and otherwise prints %.1f. The Vital Signs detail screen never passed it — even though detail.format is right there and drives the Min/Avg/Max row two lines below the chart. Same screen, two formatters, no shared source.

Their list is the accurate half of a clean split. Every metric formatted it.roundToInt().toString() disagreed with its own graph — recovery, rhr, hrv, rest, fitness_age, vitality, vo2max_est, steps_est, active_kcal. The three that already agreed (strain, resp, skin) were the ones never rounded.

This is the unfinished half of #463

formatValue exists because of that report: Trends' Effort chart tapped to the stored 0–100 figure beside a 0–21 axis. The parameter was added and only that call site was wired up. Three of twelve ever passed a formatter; the rest kept the default. So this isn't a new defect, it's the same one on the screens #463 never reached.

The change

Seven call sites, each given the formatter its own screen already uses beside the chart:

screen	formatter
Vital Signs detail (reported)	detail.format + unit
Explore	MetricSpec.format
Stress	one decimal, matching the Today/Avg/Peak footer
Sleep metric sheet	spec.format + unit
Sleep hours ×2	hours with a unit
Sleep debt	a duration (7h 20m)

BarChart had no formatValue parameter at all — it hardcoded null — so its three scrubbable call sites couldn't be fixed from outside. Added, with the same default and fallback as LineChart's.

The rule I applied, since the app was already split on it

Each chart's scrub label matches the read-out beside that chart — including the unit when that read-out carries one. That is why the vital detail scrubs 62 ms and Stress scrubs a bare 2.0.

Worth stating because the existing sites disagree: TodayScreen and SleepScreen include units (72 bpm), TrendsScreen does not (its formatY is an axis formatter reused for the label, and that chart carries several metrics). I did not touch TrendsScreen to force uniformity — a shared axis formatter has a good reason not to carry a unit, and the reporter's complaint was about a graph disagreeing with the screen it sits on, not about cross-screen consistency.

Explore was worse than a decimal

Its values are the raw stored numbers, and MetricSpec.format is what rescales Effort to WHOOP's 0–21 axis. The Y labels and the hero went through it; the scrub read-out did not. On that scale the axis said 12.4 and tapping the same point said 59 — a different value, not a different precision. That is the #463 failure verbatim, still live on that screen.

A consequence worth naming

A rounded metric now reads rounded on tap: HRV scrubs as 62 ms where it used to say 62.4. That is the alignment asked for, and the stored value is no more trustworthy than the headline implies — but it is a visible loss of detail, not a pure tidy-up. Someone will notice.

What I did not change

The shared default. A chart with genuinely fractional data still wants its decimal, and after this no scrubbable chart reaches the fallback — verified by walking all twelve call sites, not by assuming. Changing formatLineValue would also alter charts where the label is never drawn.

The reporter's second point — that Effort deserves a decimal on the 0–21 scale — is already true (LiquidTodayView does decimals: effortScale == .whoop ? 1 : 0, and #1660 extended the same rule to the trends report). The ask there was consistency, not new precision.

"stress" appears in their list but there's no stress key in the vital-detail catalogue, so that's a different surface. The Stress screen's own chart is fixed here; if they meant something else I'd want to see which screen.

iOS parity: the same parameter, wired everywhere

I first assumed iOS was safe because TrendChart.valueFormat defaults to a rounded int, so a forgotten formatter agrees with a rounded headline rather than contradicting it. That's true about the default and wrong about the reason — iOS never reaches it. Auditing every call site:

• TrendChart: 7 of 7 production sites pass valueFormat
• OverviewHRChart: 2 of 2 (the third is a #Preview with synthetic sin() data)

So Apple has no instance of this in either direction, not because the fallback is kinder but because the wiring was finished. Android was at 3 of 12. This PR brings every scrubbable chart across.

A useful confirmation fell out of it: iOS's Stress chart already passes valueFormat: { String(format: "%.1f", $0) } — the exact formatter this PR gives Android's Stress chart. The Android choice converges on shipped iOS behaviour rather than inventing one.

Verification

6 new tests pinning the divergence beside each fix, so a future caller that forgets one has a written statement of what goes wrong:

lineChartSelectionLabel(62.4, null)         == "62.4"     // what the graph said
lineChartSelectionLabel(62.4, roundedMetric) == "62 ms"   // what the screen says
lineChartSelectionLabel(2.0, null)          == "2"        // near-integer collapse
lineChartSelectionLabel(2.0, stressScore)   == "2.0"      // the footer's reading
lineChartSelectionLabel(59.0, null)         == "59"       // Explore, raw
lineChartSelectionLabel(59.0, toWhoopScale) == "12.4"     // Explore, the axis

Android 4516 tests green, compileFullDebugKotlin clean, doc_comment_lint and i18n_audit --ci clean. Android-only, so no app-build run is needed. Not hardware-dependent; no BLE path touched.