### System details
Intel Core Ultra X7 358H, Intel Arc B390 (Panther Lake), Omarchy 4.0.4-1, Quickshell 0.3.1-1

### What's wrong?
When the Bluetooth controller resets (for example, on system resume from sleep/suspend or driver reset where the PCIe/USB Bluetooth device reinitializes), the system Bluetooth daemon (`bluetoothd`) recovers cleanly, and `bluetoothctl` works normally.

However, in `omarchy-shell` (Quickshell), `Bluetooth.defaultAdapter` drops to `null` and fails to re-bind to the re-registered adapter. This causes the `omarchy.bluetooth` panel widget to become stuck in a non-functional "Off" state:

1. In `Panel.qml`, `root.adapter` is bound to `Bluetooth.defaultAdapter`.
2. When `adapter` is `null`, `checked: !!root.adapter && root.adapter.enabled` evaluates to false, and the status text displays "Turned Off" / disabled opacity.
3. Clicking the power toggle does nothing because `toggleBluetooth()` starts with `if (!adapter) return`.

Running `omarchy restart shell` immediately restores functionality, confirming that the system Bluetooth stack is healthy and only the running shell process is stuck with a stale/null adapter reference.

---

### Steps to Reproduce
1. Start Omarchy shell with Bluetooth powered on and functioning normally.
2. Trigger a Bluetooth controller reset (e.g. wake from sleep/suspend on hardware with Intel CNVi Bluetooth / PCIe driver `btintel_pcie` or similar controller reset).
3. Confirm with `bluetoothctl show` or `omarchy-bluetooth-power is-on` that Bluetooth is active and `Powered: yes`.
4. Open the `omarchy.bluetooth` panel in the bar.
5. Notice that the power switch shows "off", devices are missing or empty, and clicking the switch silently fails to do anything.
6. Run `omarchy restart shell` -> Bluetooth panel immediately shows active adapter and devices again.

---

### Relevant Logs (Sanitized)
```text
# Kernel log during wake/reset:
kernel: btintel_pcie 0000:00:14.7: resetting
kernel: btintel_pcie 0000:00:14.7: reset done
kernel: Bluetooth: BT reprobe failed for BDF:0000:00:14.7
kernel: Bluetooth: hci0: Found device firmware: intel/ibt-00a0-01a1-pci.sfi
kernel: Bluetooth: hci0: Firmware loaded in 546658 usecs
kernel: Bluetooth: hci0: Device booted in 45433 usecs

# System state after recovery:
$ bluetoothctl show
Controller XX:XX:XX:XX:XX:XX (public)
    Name: host
    Alias: host
    Powered: yes
    Discovering: no

$ omarchy-bluetooth-power is-on
(exit code: 0)

# Running Quickshell instance state:
Bluetooth.defaultAdapter -> null
Bluetooth.adapters.values -> []
```

---

### Potential Root Cause & Mitigation
1. **D-Bus Adapter Re-Registration**: When the controller resets, BlueZ temporarily unregisters `/org/bluez/hci0` and registers it again. In a long-running Quickshell process, `Quickshell.Bluetooth` does not re-acquire `defaultAdapter` when the adapter reappears on D-Bus.
2. **Defensive handling in `omarchy.bluetooth`**: In `Panel.qml`:
   ```qml
   function toggleBluetooth() {
     if (!adapter) return
     Quickshell.execDetached(["omarchy-bluetooth-power", adapter.enabled ? "off" : "on"])
   }
   ```
   Because `if (!adapter) return` aborts early, the user is unable to toggle or trigger power recovery from the UI when `adapter` is null. Permitting the helper `omarchy-bluetooth-power` to run or detecting a missing adapter to prompt/trigger a rescan would prevent the UI from silently deadlocking.

---
*Note: This issue report was generated by the AI assistant (Antigravity).*