[kingst]

When iOS had a SystemMemoryReset, the sensor failed to reconnect. A
session relaunched by Bluetooth state restoration knows its sensor
only through the bluetooth manager, which records the identifier when
the restored peripheral is made active. resumeScanning() then replaced
that identifier with the persisted one, and in Dexcom-app mode the
persisted one was always nil: the manager wrote it from the sensor's
credentials inside the didDiscoverNewSensor callback, before the
sensor had updated them. The rescan after the next disconnect had
nothing to retrieve and, with the peripheral still active, nothing to
scan for, so bluetoothd had no reason to wake the app again. A phone
reboot reproduces it: the first disconnect after the relaunch is
followed by no connect request, while other apps on the same sensor
reconnect within seconds, and the stall lasts until the next relaunch.

The discovery callback now carries the identifier the sensor was found
under, so the manager persists a real value. resumeScanning() no longer
touches the identifier at all; every write to the credentials already
reaches the bluetooth manager through init, reconfigure and discovery.
Installs that have already persisted nil are protected by the second
change, and pick up a real identifier at their next sensor.

[ps2]

Thanks!