## Summary

The `omarchy.bluetooth` bar widget's `discoveryRetry` timer re-issues `StartDiscovery` every 1 second indefinitely whenever the adapter rejects it (e.g. "Operation already in progress", adapter mid power-up, or a wedged controller). While the panel was open on this machine it spammed the BT controller ~1 Hz for minutes, and the A2DP output for the AirPods Pro was lost until a full power cycle (the controller's LE scan setup kept failing with `EINVAL/-16`).

## What happened

Opening (or leaving open) the Bluetooth panel while `StartDiscovery` was rejected produced an unbounded 1 Hz flood of retries:

```
Sep 26 21:06:27 flowstate omarchy-shell[1910]: WARN quickshell.bluetooth.adapter:
  Failed to start discovery on adapterBluetoothAdapter(0x7cc704998bc0, path="/org/bluez/hci0"):
  "Operation already in progress"
```
(repeating once per second, 21:06:27 → 21:06:57+)

Simultaneously the kernel showed the controller rejecting LE scan setup:

```
Sep 26 21:06:27 flowstate kernel: Bluetooth: hci0: Opcode 0x2041 failed: -16
Sep 26 21:06:27 flowstate kernel: Bluetooth: hci0: start background scanning failed: -16
```

Downstream: the AirPods control link could not hold (`librepods`: "AirPods control link lost: socket disconnected"; exit counters `reconnect_attempts_total=28 reconnect_failures_total=22`), and no usable A2DP sink remained until a hard reboot re-initialized the controller.

## Expected behavior

The retry loop should back off (and ultimately stop) when `StartDiscovery` keeps being rejected, instead of retrying unconditionally every second.

## Steps to reproduce

1. Get the BT adapter into a state that rejects `StartDiscovery` (mid power-up, another client holding discovery, or a wedged controller).
2. Open the Bluetooth bar widget and leave it open.
3. Watch `omarchy-shell` journal: `Failed to start discovery ... "Operation already in progress"` every ~1 s.

## Suggested fix

In `shell/plugins/panels/bluetooth/Panel.qml`, the `discoveryRetry` Timer (~line 507): track consecutive failures and back off the `interval` (e.g. exponential up to 10–15 s), and cap total attempts. The code already acknowledges the "nudging back on" intent — it just lacks a rate bound when the adapter never confirms.

Workaround: clone `omarchy.bluetooth` into `~/.config/omarchy/plugins/` and patch the same timer (what I did locally).

## System

- Omarchy Package: omarchy 4.0.4-1
- quickshell 0.3.1-1
- Kernel: 7.2.5-3-omarchy x86_64
- Hyprland 0.56.2, BlueZ 5.87-2, PipeWire 1.6.8, WirePlumber 0.5.17-1
- Controller: AzureWave (mt7925e), ASUS laptop; AirPods Pro (A2698) as A2DP sink

- omarchy debug log (24h): https://logs.omarchy.org/PM1tvs