What changed

Fixes the case‑open popup misbehaving when you're wearing one AirPod and the other is in the case. In that situation the popup would flicker — re‑appearing about half a second after you closed the lid — and sometimes stay on screen until you dismissed it by hand. It now shows once when you open the case and dismisses reliably when you close it (or when the AirPods go out of range while open).

Closes #598

Technical Context

• Root cause: with one pod out of the case, the out‑of‑case pod broadcasts advertisement frames whose case‑lid byte is stale and decodes to a phantom "open" even while the case is physically shut. These are interleaved ~1:1 with the correct in‑case‑pod frames, so the derived lid state flapped OPEN↔CLOSED. Confirmed on AirPods Pro 1 (reporter's debug log) and reproduced on AirPods Pro 3 via live BLE logcat — the out‑of‑case frame is bit4‑only (status bit6=0), the in‑case frame is bit6=1.
• The lid bit is now only trusted from a frame broadcast by a pod that is itself in the case (status bit 6) or while both pods are in the case (bit 2). A bit4‑only "one pod in case, this pod out" frame decodes to UNKNOWN, and the real state is recovered from a recent in‑case broadcast. This matches LibrePods' decoder, which gates on isThisPodInTheCase.
• The history recovery is bounded by time (~2s) rather than a fixed frame count, so a missed CLOSED across a BLE scan gap can't keep resurrecting a stale OPEN.
• The "won't dismiss" symptom needs a separate backstop: if the AirPods leave BLE range while the lid reads OPEN, no CLOSED frame ever arrives. A freshness check dismisses the popup ~4s after the OPEN broadcast stops refreshing. It tracks BLE freshness specifically (ble.seenLastAt), not overall device freshness, so a live AAP socket can't keep a stale lid on screen.
• The popup and auto‑connect flows now key their de‑duplication on the derived lid state, not just the raw advertisement bytes — the effective lid can change (recovered from history) while the selected frame's bytes stay identical, which would otherwise swallow the show/hide transition.
• Not addressed here (deliberately, to keep the change scoped): BlePodMonitor's snapshot selection can still pick a bit4‑only frame as the visible snapshot. The derived lid state is correct regardless, so this is now cosmetic (it can briefly surface that frame's battery/RSSI). The popup overlay is shared with the connection popup, so a stale‑close can dismiss a visible connection popup when both toggles are enabled — this is pre‑existing overlay behavior, not new here.

Review checklist

• Decoder: bit4‑only (one‑pod‑out) frames → UNKNOWN; bit6/bit2 frames unchanged (DualApplePodsTest)
• getLatestCaseLidState recovers CLOSED from in‑case history for a phantom current frame and never surfaces a phantom OPEN
• Stale‑close keys off device.ble?.seenLastAt (BLE), not AAP/cache
• No regression for AutoConnect CASE_OPEN or the overview lid display now that UNKNOWN can be returned
• De‑dupe keys on caseLidState (popup + auto‑connect) so derived‑lid transitions aren't swallowed