Fix alarm sound session activation failures in background

[bjorkert]

Fixes #590 — Unable to play alarm: Session activation failed.

Background activation of a non-mixable .playback audio session is denied by iOS with cannotInterruptOthers (560557684) unless the app is already actively playing audio. With Silent Tune the silent loop holds a mixable session alive, so activation succeeds. With a Bluetooth-heartbeat refresh (Dexcom / RileyLink / Omnipod Dash) there's no warm session at the moment of alarm, so setActive(true) fails and the alarm is silent.

Changes

• AlarmSound.swift — at the five setCategory call sites, choose options: based on app state:

  • foreground OR backgroundRefreshType == .silentTune → [] (legacy aggressive interrupt — no behavioral change for those users)
  • background AND not Silent Tune → .duckOthers (mixable; permits activation)

  Centralized in a new sessionCategoryOptions() helper.

• AlarmManager.sendNotification — accepts an optional soundFile: SoundFile?. When provided, the notification uses UNNotificationSound(named: "<soundFile>.caf") instead of .default.

• Alarm.trigger() — passes the alarm's soundFile to the notification only when both playSound is true AND we're in the fail-prone state (background + no Silent Tune). The system-delivered notification then carries the user's configured alarm sound as an audible fallback in case the in-app player can't activate. In foreground / Silent Tune the notification keeps .default so it doesn't echo the in-app loop.

[bjorkert]

Changed it to draft, needs more testing.

[marionbarker]

Test

✅ successful test

Demonstrate the problem

Build using dev: 6.0.9, c9f74f4

• configured LoopFollow phone with a RileyLink for background refresh
• enable high and low alerts configured so I should get an alert and lock the phone
• wait after CGM update - no alert sound
• unlock phone, check alert status - see an alert but did not hear one
• wait while app is open - alarm sounds

Demonstrate this PR fixes the problem

Build using fix/alarm-audio-session-activation, 54c2a5d

• enable high and low alerts configured so I should get an alert and lock the phone
• wait after CGM update - ✅ alert sounds even though phone is locked.

[marionbarker]

approve by test

[dnzxy]

The .duckOthers gating is a reasonable fix for cannotInterruptOthers, but I don’t think the notification path is safe as written. Since the notification with custom sound is scheduled before in-app playback is attempted, it can double-play when .duckOthers succeeds.

I'd suggest to please either make the notification sound truly conditional on playback failure, or intentionally make the background/no-Silent-Tune path notification-only.

We could also consider using applicationState == .background instead of != .active, and centralize the duplicated policy logic.

[dnzxy]

Isn't something like potentially safer to avoid unintended duplicate plays?

let playbackStarted = AlarmSound.play(...)

if !playbackStarted && inBackgroundWithoutSilentTune {
    AlarmManager.shared.sendNotification(
        title: type.rawValue,
        actionTitle: ...,
        soundFile: soundFile
    )
} else {
    AlarmManager.shared.sendNotification(
        title: type.rawValue,
        actionTitle: ...,
        soundFile: nil
    )
}