What changed

Fixed an issue where the device settings screen for connected AirPods would suddenly hide all controls (Noise Control, Conversation Awareness, etc.) when used in crowded Bluetooth environments — typically reproducible while commuting on trains or in busy public spaces. Settings now remain accessible as long as the AirPods are still connected, even if Bluetooth LE advertisements get drowned out by surrounding devices.

Technical Context

• Root cause: DeviceMonitor.devices had two merge branches for building each unified PodDevice — liveDevices (when a BLE snapshot was present) and cachedOnlyDevices (when only cache existed). The cached-only branch hardcoded aap = null, discarding the perfectly healthy AAP L2CAP connection whenever the BLE scan went stale (every 20-30 s in crowded RF environments). PodDevice.isAapConnected then flipped to false and DeviceSettingsScreen removed every settings item from the LazyColumn.
• Why crowded areas only: in low-noise environments BLE advertisements arrive frequently enough to keep the device in liveDevices, masking the bug entirely. The reporter could only repro on trains and in busy areas.
• AAP is independent of BLE: the L2CAP socket runs over the bonded BR/EDR link and is unaffected by BLE scan visibility, so the data needed to keep isAapConnected = true was always available — the merge just discarded it. The user-reported "AAP unstable" hypothesis didn't fit; the debug log shows AAP messages arriving 18+ seconds after the BLE eviction timestamp.
• Fix: extracted a small forProfile helper on Map<BluetoothAddress, AapPodState> and routed both branches through it, so they cannot silently drift apart again — this exact bug came from drift between branches.
• Why profile.address only (no cached.address fallback): AapAutoConnect early-returns if profile.address is null, so AAP can never be active for a profile with a null bonded address. Adding a cached-address fallback would only create a risk of binding to a stale address from a previous run.
• Regression test: added DeviceMonitorTest with 4 cases including the exact Settings disappear when not seen for >=25 seconds #483 scenario (BLE absent + cache present + AAP present → AAP must stay attached).

Verified end-to-end on a Pixel 8 with bonded AirPods Pro 2 USB-C: temporarily shrank STALE_DEVICE_TIMEOUT to 2 s to force continuous eviction, observed the settings UI remain visible across ~19 consecutive Removing stale device from cache log entries, and confirmed an ANC mode change command still successfully reached the AAP socket while BLE was stale.

Closes #483