[ryanbr]

Two changes to how skin temperature reads. Reported on #1842 → #1844, with the Settings choice as #1846.

Lead with the temperature, not the delta

The Today card and the detail screen showed 0.0 Δ°C — a deviation against a baseline neither screen names. The Health tile already solved this, and the rule is the whole argument:

A deviation with no anchor cannot be read — "+0.9" is a fever or a warm bedroom and nothing on the tile says which — so the absolute leads and the deviation becomes the context beneath it.

#1663 stored the nightly absolute (dailyMetric.skinTempC); #1665 applied it to the Health tile. Three surfaces never came onto that pattern and still read skinTempDevC only — Today's "Your Cards" row, the Key Metrics tile, and the HealthScreen detail (title, unit, chart and every readings row). Apple's two Today layouts had the same gap.

TodayView.dashboardValue was worse than the Android card that was reported: .hrv, .restingHr and .skinTemp had no carry at all while their neighbours carried, so a straight port of the Android change would have left it broken.

Δ°C is not the defect and stays wherever a deviation is genuinely what is shown (#622 added it so -0.1 °C is not read as a broken thermometer).

The carry had to change with it

lastSkinTempRow selects on skinTempDevC, so it walks past a CALIBRATING night: the deviation is null until the baseline is usable (~4 nights), while the absolute is measured from night one. Those wearers saw an empty card with a real temperature sitting behind it.

lastSkinTempReadingRow takes a row holding EITHER number. That OR predicate is deliberate and is not the #1842 defect, and both selectors say so in their docs: #1842 read field X off a row chosen on (X or Y), so a row holding only Y blanked X. Here the value is "whichever of the two this night has", and the caller reads both fields off that row — so an absolute is never paired with another night's deviation.

The setting (#1846)

Absolute is the right default but not the right answer for everyone — the ±baseline move is the more sensitive illness signal. Settings → Units → Skin temperature: Temperature (default) or "vs baseline", both platforms.

It is a PREFERENCE, not a filter: leadReading gains prefer, which picks the number tried FIRST; the other stays the fallback, so a choice can never blank a card whose night measured only the other. The unit always names the scale ACTUALLY shown, never the one asked for.

Wired at the call sites, not defaulted inside — dashboardCardValue, buildVitalDetail and BodyVitalSigns.readings take the resolved preference the way they already take tempUnit, and on the detail screen it is also a remember key so flipping it rebuilds rather than serving a cached model.

Caught before shipping: Kotlin persisted Kind.name ("DEVIATION") while Swift persisted rawValue ("deviation") under the same units.skinTempDisplay key. Kotlin's Kind gains a raw matching Swift byte for byte plus fromRaw, with a test pinning the tokens — the drift KeyMetricSkinTempTest exists to catch.

What the re-review changed

• The Health tile ignored the setting on both platforms; it now goes through the same leadReading rule. A setting reaching two of three surfaces reads as broken rather than absent.
• Six latestVital(...) calls took the new parameter's default; zero passed it.
• That row's predicate was skinTempDevC != null, so it walked past a calibrating night — the same bug as the carry, one layer down.
• units.skinTempDisplay was whitelisted for backup but export and import are explicit per key, so it would never have restored. Both halves wired, "" = key-absent like units.temperature.
• resolveSkinTempDevC had no caller left; deleted, and its four carry-order cases repinned onto the new resolver.
• The two Kotlin Today surfaces did not agree while the iOS twin's comment claimed they could never disagree — Your Cards read vd (carriedDay ?: day), so a live carry hid a temperature measured today, which todaysOwnReadingWinsOverEitherCarry has asserted against all along.

Verification

• Kotlin: full suite 5113 / 0, 19 new cases.
• Swift: WhoopStore XCTest for the new selector. StrandAnalytics will not build on Linux (GRDB's CSQLite), so leadReading/formatReading were run by extracting them verbatim into an isolated harness against the Kotlin's own fixtures — all pass, including that Today: HRV and Resting HR cards read "No data" while the tile above shows a value #1842's signed zero still holds.
• i18n and doc-comment gates clean. One new Android string in all 6 locales; one Apple a11y label spliced across all 9 (58 insertions, 0 deletions — no JSON round-trip). Segment labels reuse existing translated keys.

Note for testing

skinTempC landed 2026-08-27 and refills on the next scoring pass, re-derived from raw skinTempSample rows still on disk — analyzeRecent re-scores a 21-night window per post-sync pass. On an install whose newest reading predates 27 Aug this is correctly invisible until then, and nights whose raw samples were already pruned stay deviation-only for good.

[ryanbr]

Correction to this PR's body: it states that no Swift twin of the Android vital-detail screen exists, so the detail-screen change was Android-only.

That is wrong. MetricExplorerView is the twin — same "as of <date>" hero, "N readings" caption and readings table. I searched for a marker string that only Android has and concluded from its absence.

The consequence is a real parity gap, not just a documentation slip: Apple's explorer sources skin temp via Repository.dailyColumn → skinTempDevC, so it still leads with the deviation and ignores the #1846 setting. Filed separately, with why it needs its own branch rather than a change to the shared mapper (dailyColumn also feeds Trends and the catalog availability check).

Nothing merged here is wrong — the Android and Today-surface changes stand. The gap is what #1845 did not do.