Fix Live Activity cooperative-pool starvation deadlock

[loopkitdev]

Problem

LiveActivityManager.getGlucoseSample(unit:) and getInsulinOnBoard() bridge async work to sync using DispatchGroup.wait(timeout: .distantFuture). Both are called from update(), whose body runs inside a Task { … } — i.e. on a Swift Concurrency cooperative-pool thread.

Blocking a cooperative-pool thread violates the pool's forward-progress guarantee. The pool is sized to the CPU core count. Each update() that reaches one of these methods parks a pool thread on the .distantFuture wait, while the inner Task { await … } that would call .leave() needs a pool thread to run. As update() calls stack up, every cooperative thread ends up parked and no thread is left to complete the inner work — the entire concurrency runtime wedges and Loop stops looping.

Note the blocking call is a read of Loop’s local glucose store (glucoseStore.getGlucoseSamples, backed by Core Data), not a fetch from the CGM — so this is independent of CGM type and glucose-fetch latency.

update() is fire-and-forget with no concurrency limit: LoopDataManager.updateDisplayState() calls it without await, and it just spawns a detached Task on the cooperative pool. It is driven by store-change notifications (glucoseSamplesDidChange, valuesDidChange, carbEntriesDidChange, preferences), not a timer. The pool self-heals while any thread is free, so the wedge requires a burst of pool-width-many overlapping calls — e.g. several glucoseSamplesDidChange from a glucose backfill, or glucose+dose+carb changing around one loop cycle. That is not a high steady rate; it just has to reach the pool width once. (The captured report showed exactly 6 such threads, matching the device core count.)

Evidence (captured on device)

A forced report off a hung install showed all cooperative-pool threads (com.apple.root.utility-qos.cooperative) stuck identically:

LiveActivityManager.getGlucoseSample(unit:)
  → DispatchGroup.wait
    → _dispatch_group_wait_slow → __ulock_wait

…with the five RemoteDataServicesManager Nightscout upload queues blocked on semaphores behind them (their async completions also needed the starved pool). The main thread was idle in its run loop — the freeze was the concurrency runtime, not the UI thread. (The affected device was running a local BLE Libre CGM at the time; the deadlock does not depend on the CGM in use.)

Fix

• Make getGlucoseSample and getInsulinOnBoard async and suspend via withCheckedContinuation instead of blocking. A never-firing completion now merely suspends the task — it can no longer starve the pool.
• Make getBottomRow async and iterate (instead of .map) so the IOB query stays lazy — issued only for the .iob row, exactly as before.
• Update the two call sites in update() to await.

No behavior change other than not blocking the cooperative pool.

[marionbarker]

Test

✅ successful build with this modification

Start with LoopWorkspace dev branch.
Modify Loop to point to loopkitdev:fix/liveactivity-cooperative-pool-deadlock
Build onto SE 3rd gen test phone running iOS 26.
Live Activity is enabled and works.

[marionbarker]

I approve from test. Leaving the code review to the experts.