[jeremybarnum]

Lets the watch read the G7 directly. It replaces #65, rebased on current next-dev, from my fork so maintainers can push edits. Two upstream commits are kept as they were.

While it is possible for the Loop Watch App to read G7 BG analogously to how the phone does it, doing so under the conditions in which SportMode is used increases the probability of triggering a known Dexcom problem that results in losing BG for both Loop and Dexcom D2W on the watch. Therefore, this build adopts directAuth only on the watch, with a fix to avoid the Dexcom problem.

What's in it:

• A watchOS target, and the watch's own way of reaching the sensor between readings.
• Hand-off: the phone passes the watch the sensor's identity and pairing code (exportConfiguration() / init(adopting:localState:), from LoopKit's new protocols), replacing receivePairingCode. Where a watch-only #if was really about "this manager was set up by another device", it's now a run-time check instead.
• A manager set up by another device keeps its sensor until that device says the sensor changed. The kit already knows each sensor's own session length (10 or 15 days), so Loop's old watch-side age check, and its 15.5-day bound, are no longer needed.
• Faster pairing (Pete's commit): about 145 ms down to 2.5 ms per key calculation.
• One #if os(watchOS) remains: it creates the watch's way of reaching the sensor, which lives in a watch-only file.

Changes on the phone even without the Loop PR:

• The faster pairing code runs on the phone too.
• Some Bluetooth calls hop to the manager queue asynchronously instead of synchronously, and there's more logging.
• The G7 settings screen shows a "Watch Direct Read" (pairing code) section whenever a paired watch has Loop installed.

Needs LoopKit/LoopKit#626; merge that first. Builds against stock next-dev with it, and the kit's 176 tests pass.

Update: direct to watch lands first

Jeremy agreed that direct to watch (DTW) lands ahead of Sport Mode; the Sport Mode PRs get updated after. Two commits on top:

Watch acquisition: fixes from a week on a watch (5db6301, with @EJM0 and @kristinkand)

• Missed bursts are counted from when acquisition started, not only from the last reading, and a bootstrap scan stops at its cap.
• A connect or disconnect that state restoration hands back half-finished is cancelled and looked at again after 2 s and 7 s. A restored close keeps the 35 s wait; a restored connect lodges at once.
• The 35 s wait after a reading stays. A real G7 keeps advertising for ~26 s when a display is missing. A watch that connects into that tail gets a link that fails to establish (bluetoothd reason 762). watchOS counts those, and five in about 5.8 h make it connect only above −70 dBm, which on a wrist usually means never. We confirmed this on a watch: with the wait set to 0, two 762s took it to the −70 floor. CoreBluetooth's start-delay option doesn't help on the watch.

Rebond a reconnect, explain an unfinished pairing, a Read on Apple Watch setting (651c2a4)

• If a reconnect authenticates but isn't bonded, the kit runs the certificate exchange again. If that fails, it falls back to the re-pair from Decode calibration replies, expire stale calibrations, keep the display type, recover unbonded reconnects #98.
• A pairing that never finishes bonding raises an alert, which is withdrawn at the next reading.
• Read on Apple Watch toggle in G7 settings, off by default. The phone shares the sensor with the watch only while it's on (isConfigurationSharingEnabled, SportMode - necessary LoopKit changes to allow a watch controller  LoopKit#626). It replaces the "Watch Direct Read" section. Its footer notes that the watch slot conflicts with Dexcom's own watch app.
• The settings card counts down to the next reading.

The Loop side is LoopKit/Loop#2605. It runs the G7 manager on the stock Loop watch app, behind the toggle.

Tested on an Apple Watch Series 9 with a real G7 and the phone's Bluetooth off: the watch read every window in the background. 196 tests pass, and the watchOS target builds.

[EJM0]

G7 reconnect fails with 050102 after the system Bluetooth bond is lost

When it happens
The sensor is already paired, so the shared key is stored, but the OS-level Bluetooth bond is gone. This happens when the sensor is forgotten in Settings › Bluetooth, or when watchOS/iOS drops its bonds. On the next connection the stored key still passes the challenge, but the sensor reports bond=2 (bond required):

Authenticating with the saved key
Challenge: the sensor's answer verified
Challenge: verdict auth=1 bond=2
Authentication failed: Unexpected response during reconnect: 050102

The sensor then closes the link. This repeats on every connection, and the only way out is a full re-pair of the sensor.

Cause
In G7Authenticator.run, a stored-key reconnect only succeeds on auth=1 rdict throws unexpectedResponse(step: "reconnect"), including auth=1bond=2`, where the key is valid and only the bond is missing.

Fix
Throw only when the reconnect is not authenticated. If the key is acceptedrun the same certificate exchange, key challenge and bond request that afirst pairing runs:

-        if !didExchangeKeys {
+        // Authenticated but not bonded (bond=2) on a reconnect: the key is still good, only the system bond is gone.
+        // The certificate phase bonds again, as on a pairing.
+        if !didExchangeKeys, !status.isAuthenticated {
             throw G7AuthenticatorError.unexpectedResponse(
                 step: "reconnect",

Result (tested on Apple Watch + G7)

Challenge: verdict auth=1 bond=2
Running the certificate exchange (auth=1 bond=2)
...
Bonded (0801)
Sensor didRead G7GlucoseMessage(glucose: 196, ...)  + backfill

The sensor bonds again without re-entering the pairing code, and readings and backfill resume right away. A stored key the sensor rejects (auth≠1) still fails as before.