[ps2]

Backport of #103 and #104 from next-dev, for the G7 gaps reported in LoopKit/Loop#2630.

Problem

After a disconnect, the reconnect went through scanAfterDelay(), which slept 2 s on a global queue before calling connect. If iOS suspended Loop during that sleep, no connect was pending, and nothing woke the app until it was next opened.

With a G7, providesBLEHeartbeat is true, so the pump never wakes Loop for the CGM. Up to 3.14.8, the "When Open" Pod Keep Alive still polled the pod in the background. Those polls gave Loop CPU time, which let the frozen sleep finish. loopandlearn/OmnipodKit#175 removed them in 3.14.9, and since then readings can stop for hours. In LoopKit/Loop#2630 there was a 4-hour overnight gap while the Dexcom app had every reading. Silent Tune hides it by keeping the app running.

Change

• When the active peripheral disconnects or fails to connect, connect again immediately with CBConnectPeripheralOptionStartDelayKey set to 30 s. bluetoothd holds the request before the app can be suspended, and the delay lets the sensor's advertising tail pass. The value has to be whole seconds.
• When any other link ends, or the radio is down, rescan after 2 s using managerQueue.asyncAfter. scanAfterDelay() is removed.
• managerQueue_scanForPeripheral leaves an active peripheral that is .connecting alone. Otherwise the per-cycle fetchNewDataIfNeeded → resumeScanning would replace the delayed request with a plain connect.
• The reconnect line also goes to Loop's device log, through a new logEvent delegate path with default implementations.
• Remove the reconnect refusal window #104's removal of the refusal backoff is included, so a failed connect lodges the start-delay reconnect again.

Testing

• The G7SensorKit tests pass on the iPhone 17 simulator (28 tests).
• Not yet run with a real G7 alongside the Dexcom app, which is the mode dev uses. Next-dev's on-device testing of Reconnect with a start delay #103 was in direct mode.