Add a sync-status chip to the Liquid Today header (#245)

[digitalerdude]

Problem

The v8 Liquid Today header shipped with no backfill/sync indication at all —
only the classic Today header's SyncStatusChip had one, and Android already
puts its own equivalent next to the battery ring. On a WHOOP 5.0, whose history
offloads are rare, a Liquid user had no way to see a sync ever happening except
drilling into the collapsed Data Sources card (LiquidSyncStatusRow).

Closes the visible part of #245 — the "no sync indicator" report is really two
things: this always-on chip (what's missing), and a byte/percentage progress
readout (not addressed, see below).

What changed

• Extracted the state-picking logic already in SyncStatusChip into a shared
  SyncChipState.resolve(live:), so the classic and Liquid headers render from
  the exact same three-state decision (syncing / synced / 5.0 experimental /
  hidden) and can't drift on when to show what.
• Added LiquidSyncChip next to LiquidBatteryButton in the Liquid header,
  restyled to that header's own dark-hero icon idiom (.white.opacity(0.16)
  fill, matching LiquidAddButton) instead of reusing SyncStatusChip's
  light-surface chrome, which would read poorly over the photo/gradient hero.
• No Android change — it already places its SyncStatusChip next to the
  battery ring.

Explicitly not done

A commenter asked for byte/percentage sync progress (citing an old "Goose"
app). Not attempted: syncChunksThisSession's own doc comment is explicit
that the WHOOP protocol never reveals a total pending-record count, so a
chunk counter is the honest ceiling — a fabricated percentage would be
guessing.

Verification

• xcodebuild … -scheme Strand -destination 'platform=macOS' build — clean.
• xcodebuild … -scheme NOOPiOS -destination 'generic/platform=iOS Simulator' build — clean.
• New SyncChipStateTests (6 cases: each state, plus priority order between
  states) — run via xcodebuild … -scheme Strand test, all passing.
• Not yet done: seeing the chip's three states on a real strap session. This
  is a pure UI/state-plumbing change (no BLE wiring touched), but a visual
  check on-device before merging out of draft would still be good — I'll do
  that on my own WHOOP 5.0 next sync.

[ryanbr]

Reviewed (draft, so flagging what to settle before it leaves that state).

The extraction is behaviour-preserving. SyncChipState.resolve keeps the original branch order exactly — backfilling → lastSyncedAt → historySyncExperimental → nothing — and shortAgo moved verbatim. The classic chip keeps its own StrandPalette tints while Liquid gets the dark-hero idiom, so only the chrome differs. That's the right shape: shared decision, separate styling.

Android claim checks out — SyncStatusChip is already at TodayScreen.kt:2093, and Android has no Liquid/classic split, so there's genuinely nothing to mirror.

Declining the byte/percentage progress is correct, and for the documented reason rather than convenience: the protocol never reveals a total pending-record count, so a percentage would be invented. Chunks are the honest ceiling.

One finding: the chip's text isn't localized, on either header.

pill(system:text:a11y:) and the classic chip(...) both take String and render Text(text). That selects Text(_ content: S) where S: StringProtocol, not the LocalizedStringKey overload — string literals localize, String variables don't. And none of the strings are in the catalog:

ABSENT  'live'
ABSENT  'now'
ABSENT  'Syncing strap history, %lld chunks'
ABSENT  'Strap history synced %@ ago'
ABSENT  'Connected; strap history sync is experimental on this strap'

So "live", "now" and all three VoiceOver labels are hard-coded English for every locale. This is pre-existing in the classic chip rather than introduced here — but this PR duplicates the pattern into a second header, and the i18n gate can't see it (it passed): the audit looks for catalog keys, and a bare Text(stringVariable) is invisible to it.

Worth fixing while the code is open, since it's small — take LocalizedStringKey for the display text, keep the numeric interpolation, and add the five entries. Otherwise the Liquid header ships the same untranslated strings the classic one already has, in a more prominent place.

Not blocking, and the rest is clean. Your own note says the three states haven't been seen on a real strap session yet — that plus the localization would be my bar for taking it out of draft.

[ryanbr]

Checked the Android twin properly rather than just confirming it exists.

Behaviour parity holds exactly. SyncStatusChip at TodayScreen.kt:2128 uses the same branch order (backfilling → lastSyncAt != null → historySyncExperimental → nothing), the same strings, and shortSyncAgo matches your shortAgo boundary for boundary — <60 → "now", <3600 → "Nm", <86400 → "Nh", else "Nd". Nothing to fix there.

Test parity is what this PR changes. iOS gains SyncChipState as a testable enum with your 6 cases pinning the state machine. Android keeps the same logic inline inside the @Composable, where it can't be unit-tested. So after this lands, reordering the priority — say putting historySyncExperimental above lastSyncedAt — fails a test on iOS and silently diverges on Android.

That's worth closing while the shape is fresh, and the repo already has the pattern: TodayScoring.kt exists precisely to hold pure logic lifted out of TodayScreen.kt. A SyncChipState sealed class there with the same six cases would make the twin real rather than nominal.

And the localization gap is both platforms, not just iOS. Android's chip renders raw literals too — "live", "Syncing strap history, $chunks chunks", "Strap history synced ... ago" — with no uiString(R.string.…) anywhere in SyncStatusChip or ChipCapsule. So the five untranslated strings I flagged above are untranslated on Android as well, and have been since #245's original chip. That makes it a slightly bigger job than "fix the new Liquid chip", but also a more worthwhile one: one set of catalog entries fixes three chips across two platforms.

Neither is blocking, and neither is a regression from this PR — but the shared-state extraction is exactly the moment where making the Kotlin side match costs least.

[jbergler]

With #818 I think we can trust the pagesBehind metric - is that useful for calculating a percentage? Are chunks + pages the same, or can we get page progress somehow?

[ryanbr]

@jbergler good question, and #818 does change the picture — but there's an obstacle in the way that isn't about the metric.

Pages ≠ chunks. A page is a ring-buffer slot on the strap: pagesBehind = W − U, write pointer minus read pointer, against a ring capacity of 131072 in every capture we have. A chunk is a HISTORY_END boundary in the offload stream — the unit the Backfiller accumulates, decodes and acks. Nothing relates the two, and the strap never tells us records-per-page, so you can't convert one into the other.

But pages are the better denominator anyway, if you can get them twice. From #818's four fixtures the values are 83, 2, 8 and 494 pages behind — that's a real, bounded backlog measure, exactly the shape a progress bar wants. (P₀ − Pₙ) / P₀ where P₀ is captured at sync start.

The obstacle: we only ask once. GET_DATA_RANGE is sent from a single site — BLEManager.swift:4080, in the connect handshake, commented "refresh the strap's stored range for the watchdog" — and never again during the offload. So today there's exactly one sample, which gives you a denominator and no numerator.

Making it work needs re-polling GET_DATA_RANGE periodically mid-offload, and that's the part I'd want evidence for before building: it's an extra command on a link that's already saturated with historical frames, and #377's "offload throughput is firmware-paced (~10 records/s)" suggests the strap is the bottleneck rather than us. Whether a poll every N chunks perturbs that is a hardware question, not a code-reading one.

So I'd revise my earlier "declining percentage progress is correct" to "correct today, and newly worth revisiting". The honest intermediate is what the metric already gives you for free: a pages remaining readout rather than a percentage. One sample, no re-polling, no risk to the offload — and it turns "Syncing…" into "Syncing — 494 pages behind", which is most of the user value without any of the uncertainty.

Worth noting #821 also landed since: when the decode fails, the strap log now says so rather than silently logging nothing, which is what let the broken offsets sit unnoticed. So if a future firmware moves those fields, a progress UI built on it would have a visible failure mode instead of a mysteriously stuck bar.

[digitalerdude]

Addressed both findings in 8d49c38:

• Localization (comment): the chip's display text and VoiceOver labels now go through String(localized:) instead of a bare String, on both the classic and Liquid chip. Added the five catalog entries to Strand/Resources/Localizable.xcstrings (de/es/fr/it/pt-PT/ru/zh-Hans/zh-Hant) — that catalog is shared by both the Strand and NOOPiOS targets, so one edit covers both. Tools/i18n_audit.py --ci origin/main is clean on the Apple side.

• Test parity (comment): extracted a Kotlin SyncChipState sealed class + shortSyncAgo into TodayScoring.kt, mirroring the Swift enum's four cases and priority order exactly, and added SyncChipStateTest with the same six cases as the iOS SyncChipStateTests. SyncStatusChip/ChipCapsule now go through uiString(R.string...) for the same five strings, across Android's five shipped locales (de/es/fr/pt-rPT/zh) — since Android's chip predates this PR (Sync indicator missing (or I am dumb?) #245), this closes both the parity gap and the pre-existing localization gap in one pass, as suggested.

One thing surfaced while verifying: Android's testFullDebugUnitTest currently fails to compile for the whole module — three FakeRegistryDao test fakes (DeviceRegistryTest.kt, SourceCoordinatorAdoptionTest.kt, RegistryDayOwnerSourceTest.kt) are missing ~25 methods DeviceRegistryDao now declares (the reKey* family + pairedDevice/deletePairedDeviceRow). Confirmed unrelated to this PR — none of those three files are touched here, and the gap predates this branch. compileFullDebugKotlin (main sources) and the i18n audit both pass; I couldn't get a real testFullDebugUnitTest run locally to confirm SyncChipStateTest executes, only that it compiles. Flagging that gap separately rather than fixing it here.

Left the third thread (the pages-behind/#818 discussion) alone — that's a new feature proposal, not a fix to what's in this PR, and better scoped as its own follow-up.

[ryanbr]

Merged — thanks. The extraction is the right shape: shared decision, separate chrome, and six tests on logic that had none.

Two things I asked for in review that I've withdrawn, both mine rather than yours:

Localizing the chip strings. Pre-existing, not introduced here — TodayScreen.kt:2142 already ships "live" as a bare literal on main and shortSyncAgo already produces "now"/"Nm"/"Nh"/"Nd". You moved already-unlocalized strings into a testable type; holding that to a standard the surrounding code doesn't meet was wrong of me. Worth fixing across both platforms as its own change.

Extracting Android's SyncChipState. Pure test parity — Android's logic is correct and identical, it just isn't unit-testable where it sits. Not your job on a PR that improved the iOS side.

Worth knowing for anyone reading later: the i18n gate can't see this class of issue at all. The chip renders Text(variable) and the audit only reads literals, so green means less than it looks here.