Stale pairing connect teardown and BLE heartbeat for direct-BLE DASH pods

[ps2]

Forward-ports the fixes that landed on #141 after the eager-connect backport, none of which are on next-dev.

next-dev already has the eager connect watchdog (#133, 366380d), so that commit is not carried here. The three that follow it are.

What this brings

c7153cb — BLE heartbeat for DASH pods not using a RileyLink

setBLEHeartbeatRequest branched on podType.mayUseRileyLink, which is true for DASH as well as Eros because DASH can use a RileyLink under Pod Keep Alive. A DASH pod on direct BLE with Pod Keep Alive off therefore took the RileyLink branch and only set timerTickEnabled on a provider with no devices — provideHeartbeat was never assigned and the delayed-connect probe that produces background wakes was never scheduled. Loop asked for a heartbeat, we logged it, and dropped it.

With no wake source the app stays suspended until something else wakes it: Loop Failure alerts after gaps of 20 to 264 minutes that end the instant the app is foregrounded. Only reachable when the CGM cannot supply the heartbeat itself, so it needs a remote or networked CGM such as Nightscout — a BLE Dexcom provides its own and masks it.

Branches on whether a RileyLink is actually in use instead. The other mayUseRileyLink call sites want the "may" semantics and are unchanged.

Already on the dev line independently as #153; this is its first appearance on next-dev.

8f9b355 + 761e4ac — stale pairing connect teardown

This one is a regression already shipping on next-dev, not a new improvement. The zombie heuristic came in with #133.

didDiscover treated a pairable pod heard while .connecting with no watchdog as a stale connect and cancelled it. That cannot be distinguished from a connect issued moments ago — a peripheral keeps advertising until the link is established, and CoreBluetooth reports .connecting from the instant connect() is called.

discoverPods pre-connects any already-known disconnected pod, and timedConnect only arms the watchdog when shouldUseEagerConnect is true, which requires an affected iPhone model. On every other phone that pre-connect is unsupervised: the scan hears the pod ~0.8s later at .connecting, the zombie branch cancels it, the teardown timer reissues timedConnect (again unsupervised), the next advert cancels that, and pairing loops at the advert interval without completing. Two Xcode captures from an iPhone SE pairing an Omnipod 5 show 62 and 104 consecutive cycles.

761e4ac drops the heuristic and closes the source instead:

• endPodDiscovery cancels any .connecting peripheral. The previous autoConnectIDs exemption is what leaked the orphans — discovery adds the pod to autoConnectIDs before ending, so any later abandoned connect to a pod that had once been found was never cancelled. Only a .connected paired pod keeps the exemption.
• discoverPods cancels any unsupervised .connecting peripheral before issuing its own, so during discovery the only pending connect is ours and the discovery timeout owns it. This also covers a connect left pending across an app suspend or kill, which comes back through state restoration already .connecting.

8f9b355 only narrowed the misfire and is superseded by 761e4ac, which removes the pairingConnectIssuedAt stamp and pairingConnectZombieSeconds it added. Both are carried so 761e4ac's message resolves the SHA it references; the net effect is one commit's worth of change.

Conflicts

None. All three cherry-pick clean onto next-dev at 6106c1c.

The PR-141 conflict resolutions do not apply here — those existed only because dev predates the Pod Keep Alive rework (#125). c7153cb uses self.state.podKeepAlive, which next-dev already has, so it applies as written.

Result

Net change: BluetoothManager.swift +13/−24, OmniPumpManager.swift +10/−1.

BluetoothManager.swift comes out byte-identical to the #141 head. OmniPumpManager.swift still differs from the dev line by the expected Pod Keep Alive divergence, with the heartbeat hunk landing correctly.

Verification

** BUILD SUCCEEDED ** — LoopWorkspace next-dev, Loop scheme, iPhone 17 simulator, with this branch checked out for OmnipodKit. The usesRileyLink build break that blocks the dev line (#148) does not exist on next-dev.

Not exercised on hardware — the same gap #141 flags. The pairing loop wants a non-iPhone-16/17e phone pairing a pod; the heartbeat fix wants a DASH pod on direct BLE with Pod Keep Alive off and a networked CGM.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UVHbBJsuTRzW33Kne1CJt3

[marionbarker]

Test

✅ successful test of ble-heartbeat using CGM with no heartbeat

Configuration

Start with next-dev branch, commit 40df5dd and then point OmnipodKit to this PR and build onto an SE 2nd gen phone that is connected to an rPi DASH and is using Nightscout as a CGM (no heartbeat).

Narrative

After the build completes, confirm the rPi DASH is still connected.
The rPi is not capable of waking up from a timed response from Loop.
Disconnect the rPi DASH and pair an actual DASH.

Reproduce the issue

Restore OmnipodKit to the original commit, 6106c1c, which has the Pod Keep Alive cleanup that introduced the issue.

• Rebuild on the phone.
• Pair/Prime/Insert DASH SAW pod
• CGM does not have a heartbeat (NS as a CGM)
• wait for green loop
• 15:07 stop xcode, unplug phone, lock phone
• demonstrate that Loop stops looping
• 15:23 - unlock phone, see Signal Loss with immediate restoration

Demonstrate the fix

Point OmnipodKit back to this PR and rebuild

• wait for green loop
• 15:27 stop xcode, unplug phone, lock phone
• demonstrate that Loop continues looping while locked
• 15:45 - unlock phone, see green loop and history shows autoboluses while locked

✅ With PR, DASH pod continues to wake on command at 5 minute intervals

[marionbarker]

Approve from test (ble-heartbeat fix) and code review (cancel stale pairing deterministically).