Distinguish "connected, no data" from "not connected" (#612)

[digitalerdude]

Problem

#612 describes a strap that connects fine but never actually hands over data
(no live HR, offloads keep coming back empty) — and every surface still
honestly says "connected", while the Recording chip specifically does not:
RecordingState.resolve only checks connected in its first branch
(.recording). Fall through that, and a strap that's genuinely connected but
has never once synced — a fresh pairing, or an established WHOOP-4/generic
strap whose last several offloads are a sustained empty streak — reads
"Not recording. Strap not connected. Tap to connect.", which is simply
false.

Part 1 of #612 (surfacing the age of the last banked night on the baseline
card) already shipped. This is part 2, the "connected, but no data" signal,
scoped specifically to the gap that isn't already covered by #580's
.historyExperimental override — which still takes priority for a WHOOP
5/MG past its 2-consecutive-empty-offload threshold, unchanged by this PR.

What changed

• LiveState.sustainedEmptyOffload (new @Published bool, both platforms):
  exposes the WHOOP-4/generic empty-offload streak that EmptySyncTracker
  (and its Kotlin twin) already tracked, but which previously only reached
  the UI as free text inside lastSyncError. Set on every HISTORY_COMPLETE
  (so a productive sync clears it right away), reset on disconnect (the
  display flag only — the underlying streak counter deliberately survives a
  reconnect, unchanged existing behavior).
• RecordingState.connectedNoData (Swift + Kotlin, identical case/priority):
  connected && heartRate == nil && (lastSyncedAt == nil || sustainedEmptyOffload).
  Label stays "Connected" (still true), detail: "No live heart rate or synced
  history yet this session."

Explicitly out of scope here

• No new/more sensitive trigger — the existing 3×/2× consecutive-empty
  thresholds are untouched.
• No clickable single-bond README hint. That's a layer above the pure,
  testable RecordingState enum; a smaller follow-up.
• Android's RecordingStatusChip/recordingStateFor are currently not
  wired into any screen — pre-existing, unrelated to this PR. The Kotlin
  mirror here keeps parity for whenever that does get wired, per
  RecordingState's own doc-comment promise of a 1:1 Kotlin mirror.

Verification

• xcodebuild … -scheme Strand -destination 'platform=macOS' build and
  -scheme NOOPiOS -destination 'generic/platform=iOS Simulator' build — both clean.
• StrandTests/TodayExplainabilityTests, 46/46 (needed -testLanguage en -testRegion US — this machine's system locale is German, which the
  pre-existing copy tests are sensitive to regardless of this change).
• ./gradlew compileFullDebugKotlin — clean.
• Not verified on real hardware this session (no strap connected). Both
  the regression case (a healthy WHOOP 5.0 session still reading "Recording")
  and the new .connectedNoData case itself need a live check before this
  leaves draft.
• Android's testFullDebugUnitTest could not be run locally: an unrelated,
  pre-existing gap (three FakeRegistryDao test fakes are missing ~25
  methods DeviceRegistryDao now declares) fails test compilation for the
  whole module. Not touched here; filed separately.
• No Android device+strap test setup — the Android side of this PR is
  compile/unit-test verified only.

[ryanbr]

Solid — the state genuinely was lying ("Strap not connected" on a live link), both platforms move together, and scoping around #580's .historyExperimental override rather than competing with it is the right call. I checked the priority: historySyncExperimental is still tested before resolve, so that path is untouched as you say. Conditions are identical on both sides.

One thing to fix: the new copy is missing from the String Catalog.

"Strap not connected. Tap to connect."                    -> in catalog
"History sync is experimental on 5.0."                    -> in catalog
"No live heart rate or synced history yet this session."  -> ABSENT
"Connected. No live heart rate or synced history…"        -> ABSENT

LocalizedStringKey / String(localized:) is the right mechanism, so English is fine — but de/es/fr/pt-PT will show these two in English while every neighbouring chip string is translated. Both siblings are already in Localizable.xcstrings, so the convention is clear.

Worth knowing why CI stayed green: i18n_audit checks that each entry already in the catalog has every language. It cannot see a string that never made it into the catalog at all. Same blind-spot class as the Text(variable) gap.

The Kotlin literals are fine as-is — the whole enum is unlocalized there already and, as you note, the chip is not wired into any screen yet.