[pipiche38]

(replace the closed #1589 1589)

What this PR does

Skin Temp was already a "Your Cards" (DashboardCard) option on both platforms, but was never offered
as a small "Key Metrics" grid tile.

Found 2026-08-24 while diagnosing a "Skin Temp visible on the Deep Timeline, missing from the Cards"
report: it turned out there are two different "Cards" screens in this app, and Blood Oxygen / Skin
Temp each work on one and fail on the other. The Key Metrics grid (KeyMetric enum) simply never
had a skinTemp case, on either platform — not a display-path bug, just a tile that was never added.
(The mirror-image, genuinely-real bug this same investigation found — Blood Oxygen's "Your Cards"
drill-down having no candidate fallback — is a separate PR:
fix/oura-spo2-cards-explorer-candidate-fallback.)

Re-opens #1589, which was closed unmerged. Same change, rebuilt on current main as two clean commits
and re-verified; no functional changes from the original.

The fix

New KeyMetric.skinTemp / KeyMetric.SKIN_TEMP case on both platforms. Not added to
defaultOrder — an existing user's saved layout, and a fresh install's default, stays
byte-identical to before; the tile only appears once opted into via the layout editor.

Reuses the sibling DashboardCard.skinTemp/.SKIN_TEMP tile's existing title string ("Skin Temp"),
icon (thermometer.medium / Icons.Filled.Thermostat), and value formatting (SkinTempDisplay, the
same bimodal absolute-vs-deviation handling from #622) — no new copy, no new i18n debt. The Android
tap-through reuses the "skin" vital_detail key dashboardCardMetricKey(DashboardCard.SKIN_TEMP)
already routes to — a confirmed-working destination, not a new/unverified one.

LiquidTodayView had no temperature-unit resolution at all before this (added the same @AppStorage

• resolveTemperature pattern TodayView/MetricExplorerView already use). Android's Window
  struct gained a skinTemp trend field for the tile's sparkline, matching the iOS
  sparks["skin_temp"] added the same way.

Per ryanbr's review on #1589, TodayScreen.kt's Android tile also gained a PER-FIELD skin-temp
carry (skinTempCarryDay): carriedDay (lastScoredRecoveryDay) is a whole-row carry that lands on
rows with a null skinTempDevC, so without this the Key Metrics tile fell through to a blank value on
a night whose recovery-scored row happened not to carry a skin-temp reading. Mirrors the existing
spo2CarryDay/respCarryDay per-field fallbacks and iOS TodayView's lastSkinTempDay chain. Pulled
the shared resolveSkinTempDevC(d, carriedDay, skinTempCarryDay) helper out so the fallback chain is
independently testable without Compose/Robolectric.

Tests

4 new tests (2 per platform): the raw-token round-trip + defaultOrder-exclusion contract for the new
persisted enum case (schema-relevant — KeyMetric rawValues are the today.keyMetrics layout
string), plus the Android resolveSkinTempDevC carry-fallback tests added in response to review.

Verification (2026-08-27, on top of upstream/main @ 9bdad2d)

• Built as two commits directly on current upstream/main (the original 3-commit history — feature,
  review-fix, and a doc-lint reorder fixup — is squashed here to feature + review-fix). Resolving the
  original rebase surfaced one conflict in TodayScreen.kt (unrelated main-branch spo2CandidateByDay
  param landed on the same MetricGrid call site/signature as this PR's skinTempCarryDay), resolved
  as a straight union of both params — nothing dropped from either side; the resulting tree here is
  byte-identical to that resolution.
• Android: compileFullDebugKotlin clean; com.noop.ui.* all green (JAVA_TOOL_OPTIONS=-Duser.language=en
  to avoid the pre-existing fr_FR-locale-only failures noted in prior sessions).
• Tools/doc_comment_lint.py and Tools/i18n_audit.py --ci upstream/main both clean.
• macOS (xcodebuild -scheme Strand build): not verified this session — blocked by a pre-existing
  local environment issue unrelated to this diff (an explicit-module-cache race in the cmark-gfm
  third-party dependency; _DarwinFoundation2*.pcm not found under parallel CompileC). Not chased
  here; same env issue noted against a prior PR's macOS build. iOS build also not verified this
  session.