Oura: stable device identity from the ring's serial, and generation from its hardware id (#771, #772)

[pipiche38]

Branch: oura-serial-identity → main
Closes: #771 (stable ring identity), #772 (generation detection)

Why

Two linked defects, both because NOOP inferred an Oura ring's identity and generation from the wrong source:

• Oura: derive a stable ring identity instead of the CoreBluetooth UUID (re-pair orphans all history) #771 — a re-pair orphans all history. The device id was oura-<CoreBluetooth-UUID>. iOS can't read a
  ring's MAC (CoreBluetooth only exposes an opaque identifier that rotates on re-pair), so every
  re-pair minted a new id and stranded the ring's prior samples under the old one. Observed on device: one
  physical Gen3 ring produced four oura-<UUID> rows, the live data stranded under an archived one, and
  the dashboard reading blank because the active row had no history.
• Oura: recognise() mis-detects generation from stray digits in the BLE name; confirm via GATT layout instead #772 — wrong generation. Generation came from recognise(advertisedName:), which read any digit in the
  BLE name as the generation. A factory-reset ring advertises its serial in the name
  (Oura 2H3B2405003655), whose 5 was read as Gen5 on a real Gen3.

The fix for both is the same read: the ring's own GetProductInfo pages, already defined in the command
set but never called. The serial is the identity that survives a re-pair; the hardware id is the
authoritative generation.

What

Three tightly-linked pieces (one product-info read feeds all of them):

1. Read the product-info pages on connect (capture-first)

At .streaming, send the pre-auth get_serial (18 03 08 00 10) and get_hardware (18 03 18 00 10) —
read-only, same class as the existing SpO2 / real-steps status reads — and decode each reply. Both answer
under outer op 0x19 with the layout byte0 = status, then NUL-terminated ASCII (validated on a Gen3:
serial 2H3B2405003655, hardware BLB_03). Told apart by content: the hardware id has an _NN generation
marker, the serial does not.

2. Generation from the hardware id (#772)

• OuraDecoders.productInfoString + OuraRingGen.from(hardwareId:) map BLB_03 → Gen3 (_NN suffix;
  gen4/5 codes unconfirmed → nil, never a guess).
• recognise(advertisedName:) hardened to infer a generation only from an explicit gen/ring token,
  so a serial-bearing name yields nil (→ safe default) instead of a bogus generation.
• On connect, if the hardware id resolves a generation different from the session's, onModel →
  registry.setModel corrects the mis-stamped row on connect — no re-pair needed (the same WHOOP
  setModel-on-connect pattern as Skin Temp, Wrong Strap Model #716).

3. Stable identity from the serial (#771)

• The live source still mints the provisional oura-<CBUUID/addr> at pairing; on reading the serial page it
  fires onSerial (guarded by isPlausibleSerial: alphanumeric, 8..24, so a misframed reply can't mint a
  bogus id).
• SourceCoordinator.adoptOuraSerial re-points the active row onto oura-<serial> (prefix from the
  brand catalog, never a literal) via DeviceRegistryStore.adoptSerialIdentity(from:to:): it folds only
  the active row's data + registry into the serial id (a rename when new, an UPDATE OR IGNORE merge —
  canonical wins a PK clash — when a prior pairing established it) and deliberately leaves other past
  oura-* rows untouched. The Keychain install key is migrated onto the serial id (or the re-pointed
  session couldn't re-authenticate), then setActive(serialId) moves the read/write spine over.
• The provisional row is deleted (not archived), so future re-pairs converge onto the serial id and add
  no new "Removed" clutter.

Honest-data / scope

Read-only; no new writes to the ring. Nothing is persisted beyond a corrected model label and the re-keyed
identity. Only the active row is folded — consolidating older orphaned oura-* rows is a separate, explicit
operation (not in this PR).

Cross-platform parity

Byte-identical Swift/Kotlin twins throughout: the decoders (productInfoString, from(hardwareId:)), the
onModel/onSerial callbacks, and the reconcile (adoptSerialIdentity). Android needs per-table Room
queries (no dynamic table names), so it carries 24 reKey<Table> UPDATE OR IGNORE queries over the same
device-scoped table set as deleteDeviceData. On Android setActive is followed by onActiveDeviceChanged
to re-point (macOS gets that free from the @MainActor activeDeviceId observer).

Verification

• swift test — OuraProtocol 127/0 (incl. new RingGenProductInfoTests, 10) and WhoopStore 273/0
  (incl. 4 new adoptSerialIdentity tests: rename-when-new, merge-when-exists, leaves-other-pairings-
  untouched, no-op).
• macOS Strand BUILD SUCCEEDED; Android compileFullDebugKotlin OK (Room KSP validates the new
  queries). App-target Swift is touched, which default CI does not compile — built locally.
• The Android adoptSerialIdentity unit test is deferred: the Android test module doesn't compile until
  Android: unblock testFullDebugUnitTest — implement DeviceRegistryDao.setModel in the three fake DAOs #725 adds the three fake-DAO setModel overrides (pre-existing, unrelated); the Swift twin's 4 tests
  pin the logic.

On-device (macOS, Gen3, 2026-07-24) — the BLE path, validated on hardware

• get_serial = 2H3B2405003655, byte-identical across a factory-reset-and-adopt that rotated the
  CoreBluetooth UUID (99B6BA9D… → 4DD70E24…) — i.e. the serial is stable where the UUID is not.
• get_hardware = BLB_03 → the ring registers as Oura Ring 3 (was Gen5 before the fix).
• The re-point fired (adopted stable serial id oura-2H3B2405003655 … re-pointing); the re-pointed session
  authenticated with no key re-install (the key migration worked); the DB active row became
  oura-2H3B2405003655 with the session's HR under it, the four old archived rows untouched. A subsequent
  re-pair converges onto the same id.