### System details

Intel Core i5-6400, Intel HD Graphics 530, Intel Wireless 8265 Bluetooth (hci0, btusb, BT 4.2). Omarchy 4.0.2-1, Hyprland 0.56.2, linux 7.1.9-arch1-2, bluez 5.87-2, quickshell 0.3.1-1.

### What's wrong?

The Bluetooth panel's LE discovery scan prevents already-paired BLE HID devices from reconnecting. Dual-channel BLE mice come back from the other host advertising, stay **paired/bonded/trusted**, and never connect until the scan is gone.

This is not a dropped bond. It looks like "pairing died" because the mouse LED blinks and a click on the device in the panel does not attach it.

#### Repro

1. Pair a dual-channel BLE mouse (here: **EM01 NL**, HOG / HID-over-GATT, USB id `25A7:FAA0`, address type random). Leave a BLE keyboard paired as well (here: Split65-3); it is a control because it never drops.
2. Open the Omarchy Bluetooth panel and leave it open.
3. Switch the mouse to its other host, confirm it works there, then switch back to this machine.
4. Mouse LED blinks. Panel still shows the device as paired. It does not auto-reconnect.
5. Close the panel (or otherwise get `Adapter.Discovering` to false) and switch again: the mouse reconnects on its own.

#### What we saw with the panel/scan up

`bluetoothctl connect` (and presumably the panel click) failed with:

```
Failed to connect: org.bluez.Error.Failed le-connection-abort-by-local
```

At the same time:

- `org.bluez.Adapter1.Discovering` was `true`
- `StopDiscovery` from another client returned `No discovery started` while Discovering stayed true
- omarchy-shell logged `quickshell.bluetooth.adapter: Failed to stop discovery ... "No discovery started"`
- Device1: Paired/Bonded/Trusted yes, Connected no, RSSI present (the mouse was advertising)

Adapter power-cycle cleared the stuck scan; both HID devices came back. Repeating the channel switch **with the panel closed** auto-reconnected.

#### Why this is Omarchy

`shell/plugins/panels/bluetooth/Panel.qml` starts an unfiltered LE scan for the whole time the panel is open (`discoveryRetry` sets `adapter.discovering = true` every second while `opened`). The comments there already note that leaking this session starves A2DP on the same controller. The same scan aborts LE **connects**, which is what a dual-channel BLE mouse needs when it returns.

`discoveryStop` gives up after 3 failed attempts (`owesDiscoveryStop = false`), so Discovering can stay true after close. That matches the stuck scan we hit.

BlueZ default Policy `ReconnectUUIDs` is audio-only, so HOG mice already depend on the host connecting when they advertise. The panel scan makes that connect fail.

#### Expected

Opening the Bluetooth panel to look at a paired mouse must not block that mouse from reconnecting. Discovery should stop on close, and a bonded HID device that is advertising should be allowed to connect even if the panel is open (pause/filter the scan, or stop it around Connect).

#### Workaround

Keep the Bluetooth panel closed when switching the mouse between hosts. If it is already blinking, close the panel first.

Relevant journal snippets (full `omarchy-debug` is 1.7MB of unrelated UFW noise, not attached):

```
omarchy-shell: WARN quickshell.bluetooth.adapter: Failed to stop discovery on adapter ...: "No discovery started"
bluetoothctl connect: org.bluez.Error.Failed le-connection-abort-by-local
kernel: hid-generic 0005:25A7:FAA0: input,hidraw1: BLUETOOTH HID v5.08 Mouse [EM01 NL]
```