feat(ble): adopt a stable whoop-<serial> identity for 5.0/MG (#1303 phase 1)

[ryanbr]

DO NOT MERGE until hardware-validated — see below. Opening it now so the design can be reviewed
while a 5.0/MG night is arranged.

Phase 1 of #1303, the multi-strap keystone.

Why this is smaller than it looks

WHOOP identity is a transient CoreBluetooth UUID / Bluetooth address, so a re-pair or factory reset
mints a fresh one and the same physical strap forks into a second registry row, orphaning its history
(#1193).

The scary part — re-keying every stored row — is already written, shipped and proven:
adoptSerialIdentity migrates every deviceScopedTables row, is PK-clash-safe, is unit-tested, and has
been running on both platforms for the ring since #771. This PR does not add a migration. It calls the
proven one from the WHOOP path.

Why 5.0/MG only

Their serial is already read at connect from DIS 0x2A25 for MG-vs-5.0 discrimination — so this adds
no BLE traffic whatsoever, it consumes a value already in hand.

A 4.0 is untouched: the DIS read is explicitly gated != .whoop4, and the 4.0 serial's source on the wire
is not yet identified (REPORT_VERSION_INFO's 35 bytes are fully accounted for as firmware). Splitting
the two is precisely what lets this half ship now rather than waiting on a 4.0 protocol capture — that is
Phase 0/2, and it needs a capture, not speculative code.

The refusals are the feature

Adoption migrates every device-scoped row onto whatever id is returned, so WhoopSerialIdentity refuses a
blank, truncated, or descriptive-prose DIS read and returns nil, leaving the strap on its existing id.
Moving a history onto a garbage key is worse than not adopting. Serials are upper-cased so one strap
read in two cases cannot become two ids, and isAlreadyAdopted is the reconnect early-out — after the
first adoption it is one string compare and no database work.

Design notes worth reviewing

• Both platforms defer off the BLE callback, mirroring adoptOuraSerial: adoption re-points the ACTIVE
  device, and the observers that react tear down the very connection the callback is running inside.
• On Android it lives in AppViewModel, not SourceCoordinator — that file is documented as inert on
  the WHOOP path and never touches WhoopBleClient internals. AppViewModel already owns the registry
  handle and a scope. (I wired it into SourceCoordinator first and reverted; the file's own header says why.)
• The serial is a device identifier: only its 3-char prefix is ever logged, the rule
  noteWhoop5VariantFromDIS already applies. logSafe enforces it and a test pins that the full serial
  cannot appear in a shareable strap log.

Verification

• 8 mirrored test vectors per platform on the pure core (composition, case-folding, trim, and five refusal
  cases)
• Android 4,091 tests / 0 failures; Kotlin compile, i18n, doc-comment gates clean
• app-build dispatched for the app-target Swift

What must happen before merge

This is the BLE path — compiling proves nothing. A 5.0/MG night must confirm:

1. the strap adopts once, and the strap log shows the prefix-only line beside the DIS line
2. a reconnect is a no-op (no repeated adoption, no database churn)
3. a re-pair re-anchors onto the existing serial row rather than forking a new one — the actual Duplicate device entries for one physical strap — removal doesn't stick (iOS 4.0 + Android 5.0) #1193
   scenario