Fix unit/scale preferences ignored across six display sites

[digitalerdude]

What this PR does

Fixes six display sites that formatted a convertible metric without routing through UnitFormatter — the same bug class as ryanbr#101 (skin temp ignoring the Fahrenheit preference in Deep Timeline) and ryanbr#45 (Effort scale ignored on the Today hero gauge), found by sweeping the codebase for the pattern. Display-only throughout: stored values stay SI, every stat/trend/threshold is still computed on the stored values.

Site	Bug	Fix
TodayView — "Your cards" skin-temp card	Raw Δ°C formatted with "%+.1f°", °F preference ignored	UnitFormatter.temperatureDeltaFromCelsius (×9/5, no +32 offset for a delta), signed, with the resolved unit label ("+0.3 °C" / "+0.5 °F")
Trends report PDF — RangeReportEngine + TrendsReportView	Skin-temp row hardcoded "°C"; Strain shown as the raw 0–100 integer regardless of the #268 Effort-scale choice — in an artifact users may hand to a clinician	RangeReportEngine.build gains effortDisplayFactor / skinTempDisplayFactor / skinTempUnitLabel (defaults keep existing callers byte-identical), mirroring WeeklyDigestEngine's effortDisplayFactor precedent, so headline prose converts too; the page's Avg/Min/Max read-outs convert in valueText
LiquidTodayView — Key Metrics Strain tile	Raw 0–100 with a literal "%" (wrong unit + ignored the 0–21 axis), while the hero gauge and workout card in the same file already converted	Routes through effortText with a "/ 100" / "/ 21" suffix
LiquidTodayView — workout sub-line	Hardcoded "%.1f km", miles preference ignored	UnitFormatter.distanceFromMeters
FusedRecordView — "Your Data, Fused"	FusionFormat hardcoded "%.1f°C" for the absolute skin temperature	Formatter takes the resolved TemperatureUnit as a required parameter (no default, so future call sites can't silently bypass); converts via temperatureFromCelsius (full ×9/5 + 32 — absolute, not a delta)
AppModel — illness watch	Fired-signal label "skin temp +0.7 °C" (Heads-Up card, amber banner, notification) formatted the raw Δ°C	New UnitPrefs.currentTemperatureUnit() helper for non-view call sites (mirrors currentEffortDisplayFactor)

Checked and deliberately left unchanged: CoupledView (pinned to the WHOOP 0–21 axis by documented design), SkinTempCardsView (the "+0.7 °C" strings are DEBUG preview fixtures), AICoach context blocks (SI on purpose — model context, not UI), ActivityFileImporter notes (persisted at import time, Kotlin parity), Settings/AppleHealth/Workouts/WorkoutDetail (already branch correctly).

Android follow-up: the Kotlin RangeReport mirror should gain the same three display parameters to stay in lockstep — its UnitFormatter already has the effortDisplayFactor precedent from the WeeklyDigest work. The app-side sites above are worth checking on Android too.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation
• CI / tooling

How it was tested

• swift test in Packages/StrandAnalytics: 21/21 RangeReportTests pass — the new engine parameters default to the current behaviour, so the existing oracle stays byte-identical (the Kotlin twin's RangeReportTest is unaffected until it mirrors the parameters).
• Full macOS Debug build (xcodebuild -scheme Strand) is clean; the only warnings in the log are pre-existing and unrelated (actor-isolation / localization deprecations).
• No BLE-path changes — everything here is display formatting.

Checklist

• Swift package tests pass for any package I touched (swift test in Packages/<name>)
• Android unit tests pass if I touched android/ (not touched — Kotlin mirror flagged as follow-up above)
• No new build warnings introduced
• UI changes use only StrandDesign tokens — no hardcoded colors, fonts, or spacing
• No hardcoded hex frame bytes; protocol facts live in the schema / decoders
• Follows the conventions in docs/CONTRIBUTING.md
• I did not commit generated output (Strand.xcodeproj/) or any secrets/keystores

Related issues

Follow-up to ryanbr#101 and ryanbr#45 (same bug class, remaining instances). Touches the display side of #268 (Effort scale) and #457 (trends report).

🤖 Generated with Claude Code

[digitalerdude]

CI note: test (WhoopProtocol) failed with a Swift type-checker timeout ("unable to type-check this expression in reasonable time") at DecoderOracleTests.swift:86 — a pre-existing one-line optional-chained gravity-magnitude expression that exceeds the type-checker budget on the CI runners but squeaks through on local arm64 machines. Unrelated to the display fixes in this PR; ffb8ed9 splits it into typed sub-expressions (same assertions, no behaviour change) so the run can go green. All 241 WhoopProtocol tests pass.