## What happened

The Bluetooth bar panel leaks its BlueZ discovery session. After opening/closing
the panel, `Discovering` on the default adapter can get stuck `true`
indefinitely — even with the panel closed, the bar not scanning for anything,
and no other Bluetooth client (no `blueman`, no other app) holding a session.

Confirmed via D-Bus directly:

```
$ busctl --system get-property org.bluez /org/bluez/hci0 org.bluez.Adapter1 Discovering
b true
```

Consequences observed:

- `journalctl -u bluetooth` floods with device-registration errors for a bogus
  all-zero address, hundreds of times per hour:
  ```
  bluetoothd[804]: src/device.c:device_new() Unable to register device interface for 00:00:00:00:00:00
  bluetoothd[804]: Unable to create object for found device 00:00:00:00:00:00
  ```
  (611 occurrences in the last 3 hours alone on my system.)
- Two paired/bonded/trusted Bluetooth LE peripherals (Logitech MX Master 3 and
  MX Keys) stopped auto-reconnecting after wake/idle. Both showed
  `Paired: yes / Bonded: yes / Trusted: yes / Connected: no` and would not
  reconnect on their own — only a manual channel-switch on the device forced a
  fresh connection. This points to BlueZ's passive background auto-connect scan
  for bonded LE devices being starved by the radio being pinned in active
  discovery/inquiry mode indefinitely.

## Root cause (from reading the panel source)

`/usr/share/omarchy/shell/plugins/panels/bluetooth/Panel.qml` runs two timers
to manage the adapter's discovery state:

- `discoveryRetry` (while the panel is open) keeps writing
  `adapter.discovering = true` once a second so the scan survives BlueZ
  timeouts.
- `discoveryStop` (after the panel closes) is supposed to write
  `adapter.discovering = false`, bounded to 3 attempts before giving up.

The file's own comments acknowledge the race that causes the leak: if a
`StopDiscovery` write lands while a just-fired `StartDiscovery` hasn't been
confirmed by BlueZ yet, Quickshell's property dedup (it only forwards a write
that differs from the *last confirmed* state) silently swallows the stop.
After the bounded 3 attempts, `owesDiscoveryStop` is cleared and nothing ever
retries again — leaving discovery running until something external
(a full BlueZ/adapter reset) clears it.

Relevant code (`Panel.qml` lines ~504-554):

```qml
// BlueZ rejects StartDiscovery while the adapter is still powering up, and
// discovery can also time out on its own. While the panel is open, keep
// nudging it back on so an enabled adapter is always scanning.
Timer {
  id: discoveryRetry
  interval: 1000
  repeat: true
  triggeredOnStart: true
  running: root.opened && root.adapter !== null && root.adapter.enabled && !root.adapter.discovering
  onTriggered: {
    root.owesDiscoveryStop = true
    root.adapter.discovering = true
  }
}

// The way back down. ... quickshell only forwards a discovering write that
// differs from the last state BlueZ reported, so a stop issued while a
// just-fired StartDiscovery is still awaiting confirmation would be
// swallowed and leak the session.
Timer {
  id: discoveryStop
  interval: 1000
  repeat: true
  property int attempts: 0
  running: !root.opened && root.owesDiscoveryStop && root.adapter !== null && root.adapter.discovering === true
  onRunningChanged: if (running) attempts = 0
  onTriggered: {
    var sibling = root.openSibling()
    if (sibling) {
      sibling.owesDiscoveryStop = true
      root.owesDiscoveryStop = false
      return
    }
    attempts += 1
    if (attempts > 3) { root.owesDiscoveryStop = false; return }
    root.adapter.discovering = false
  }
}
```

## Expected behavior

Discovery should reliably stop shortly after the panel closes, and the app
should not give up and abandon a leaked session after 3 attempts — or should
fall back to a harder reset (e.g. re-issue `StopDiscovery` unconditionally, or
detect the stuck state) rather than leaving the radio pinned in discovery
mode indefinitely.

## Steps to reproduce

Not yet narrowed to a reliable manual repro (didn't catch it happening live —
found the adapter already stuck on this way after normal daily use of the
Bluetooth panel). Suspect it's the acknowledged unconfirmed-StartDiscovery
race in the comments above, likely more probable when opening/closing the
panel in quick succession, or with a popout moving between monitors
(`openSibling()` path).

## Workaround

Power-cycling the adapter clears the stuck session immediately:

```bash
bluetoothctl power off && bluetoothctl power on
```

After that, previously-idle bonded LE devices auto-reconnect normally again on
next wake.

## System details

- Omarchy version: 4.0.2-1 (channel: stable)
- Kernel: 7.1.9-arch1-2
- CPU: Intel(R) Core(TM) 5 320
- GPU: Intel Wildcat Lake (Intel Graphics), `xe` driver
- Affected devices: Logitech MX Master 3, Logitech MX Keys (both Bluetooth LE)

## Note

`omarchy debug --no-sudo --print` documented in the contributing guide does
not exist as a command on this installed version (4.0.2-1) — `omarchy
commands --all` has no `debug` subcommand. Happy to provide anything else
needed.