What changed

Fixed an issue where toggling the Extra notification setting in General Settings didn't take effect immediately. After turning the option off, the extra notification could remain visible until AirPods state changed enough to cause a refresh, or until the monitor service was restarted.

Also fixed a related case in Always-on monitor mode: the extra notification kept updating with cached battery data after AirPods disconnected — even when "Keep notification after disconnect" was off.

Technical Context

• Root cause: MonitorService read useExtraMonitorNotification and keepConnectedNotificationAfterDisconnect synchronously via DataStore's valueBlocking inside the device-update flow but never subscribed to the setting flows. Setting changes only took effect on the next device emission, and even then there was no cancel branch — NOTIFICATION_ID_CONNECTED was never explicitly cancelled until onDestroy().
• Fix: combined both setting flows into the device flow so any change re-runs the notification logic. Switched the "connected" predicate from currentDevice != null to PodDevice.isLive so the connected notification reflects actual BLE/AAP liveness rather than cached profile data. Added isLive to NotificationDeviceKey so live↔cached transitions emit through the distinct filter.
• Decision logic extracted into a pure decideExtraNotificationAction(...) helper, unit-tested across all 9 input combinations of (extra on/off) × (live / cached / null) × (keepAfter on/off).
• onDestroy() now reads a cached NotificationSettings snapshot (atomic @Volatile) rather than calling valueBlocking on a cancelled scope. The snapshot is seeded at the top of doMonitor() before the permission early-return so it's always valid.
• Side change: DataStoreValue.flow now applies distinctUntilChanged() on the raw preference value before reader() runs (matches the SD MAID SE pattern). Eliminates spurious re-emissions when any key in the same settings_general DataStore is written — previously every unrelated write caused extra notification updates and unnecessary deserializer work for every consumer.

Behavior change: keepConnectedNotificationAfterDisconnect = false now actually hides the extra notification when AirPods disconnect (previously it kept updating with cached data until the service died). With keepAfter = true the notification persists with the last live snapshot.

Review checklist

• decideExtraNotificationAction table covers all live/cached/null × extra-on/off × keepAfter combinations
• onDestroy() reads the cached snapshot — verify the snapshot is seeded before any return paths in doMonitor()
• DataStoreValue.flow source-level filter — quick scan of other consumers for code that relied on duplicate emissions