[ryanbr]

Reported three times before it was believed — and that is the part worth keeping. The number was plausible, so the reading was treated as mistaken rather than the label.

The defect

noop.lastSyncAtSec is one key, stamped on any strap's HISTORY_COMPLETE and read back for whichever strap is active. On a single-strap install those are the same strap, which is why it survived this long.

With two paired, it reports the other one's. From the 30 Aug capture:

Last sync:   4d ago
Days:        whoop-MGB…=0   my-whoop=37
  device id=whoop-MGB… status=ACTIVE   lastSeen=just now
  device id=my-whoop   status=paired   lastSeen=3d ago

The 5/MG had never banked a row. The timestamp on its screen was the 4.0's.

Why it was expensive

It was wrong in the reassuring direction. A strap that has never synced read as recently synced, so a pull-to-refresh that could not possibly change the number looked broken rather than inapplicable — and it sent an entire investigation after a sync regression that never existed.

The shape of the fix

This is the same defect resolveFirmware already fixed for firmware strings, so it takes the same shape:

• stamped per BLE address (the address is known when HISTORY_COMPLETE arrives; resolving to a registry id there would repeat the mis-mapping "Last seen" on the Devices card shows time-since-ADDED, never time-since-seen (both platforms) #1527 fixed for lastSeen)
• read per strap
• the legacy global honoured only when exactly one strap is paired — the one case where it cannot be ambiguous, which keeps single-strap installs reading correctly across the upgrade instead of resetting to "never"

Deliberately not migrated by writing the global onto the active strap. That is the same guess in a different place, and on a multi-strap install it would bake the wrong attribution in permanently instead of letting it self-correct at the next real sync.

The sibling line had it too

One line below, in the same capture: Data write: rows last landed 4d ago — against a strap whose own row count was zero. Two lines that both read as evidence the 5/MG had been syncing, and neither was about the 5/MG.

Both halves of the #57 write-health pair are scoped, not just the one that was noticed. They are read as a pair — "stalled more recently than ok" is the alarm — so scoping one would compare a strap's own stall against another strap's success.

What it says now

For the strap in the capture: "never (this strap)". Not a degraded answer — the correct one, and the one nobody had been given.

Notes

• No Swift twin needed; the Apple side has no persisted global equivalent.
• The seed for LiveState.lastSyncAt resolves the single-strap fallback just after construction rather than in the constructor, because the paired count needs the registry and the registry is suspend. Seeding from the global first and correcting later would have shown the other strap's timestamp for as long as that took — the bug, briefly, rather than not at all.

Verification

• 4907 tests, 0 failures
• lintVitalFullRelease, doc-comment lint, i18n --ci clean
• staging 392 / iOS 273

Related to #1635.