## What happens

Turning Bluetooth **off** from the `omarchy.bluetooth` bar widget makes the widget — and the only
control that could turn Bluetooth back on — disappear.

The off path (`omarchy-bluetooth-power off`, which the widget's switch calls) soft-blocks the radio
with rfkill. BlueZ then **removes the adapter object entirely**, so `Quickshell.Bluetooth` reports no
adapters at all. Every power control in the panel is gated on that adapter existing:

- `plugins/panels/bluetooth/Panel.qml:500` — `visible: adapter !== null` → the whole widget leaves the bar (icon gone)
- `:59` — `if (!adapter) return ""` → no icon even if it stayed
- `:715` — `visible: !!root.adapter` → the hero switch is not rendered
- `:636` — `if (!adapter) return` → `toggleBluetooth()` (switch, right-click on the icon, `b` key) can no longer turn Bluetooth on

So once it is off, nothing in the panel can bring it back; `omarchy-bluetooth-power on` from a
terminal works fine.

## Expected

The widget stays on the bar showing the off state, and its switch turns Bluetooth back on.

## Steps to reproduce

1. Bluetooth on, stock `omarchy.bluetooth` widget in the bar.
2. `omarchy-shell omarchy.bluetooth toggleBluetooth` (or click the switch in the panel).
3. `busctl --system call org.bluez / org.freedesktop.DBus.ObjectManager GetManagedObjects | grep -c Adapter1` → **0** — BlueZ deleted `/org/bluez/hci0` because of the rfkill soft block.
4. The bar icon is gone and `omarchy-shell omarchy.bluetooth toggleBluetooth` now does nothing (returns at `if (!adapter) return`).

## Second, related defect: the panel reads a state BlueZ can invalidate

`icon:`, `checked:` and `toggleHint` read `adapter.enabled` (BlueZ `Powered`), and that value goes
stale when the adapter is re-added. BlueZ emits, in order (seen with
`dbus-monitor --system "type='signal',sender='org.bluez'"`):

```
InterfacesAdded    /org/bluez/hci0            ... Adapter1 { Powered: false }
PropertiesChanged  /org/bluez/hci0  Adapter1  { Powered: true }     # ~20 ms later
```

quickshell logs the first and misses the second:

```
Tracked new adapter BluetoothAdapter(0x..., path="/org/bluez/hci0")
Updated property org.bluez/org/bluez/hci0/org.bluez.Adapter1:Powered to false
```

while `busctl --system get-property org.bluez /org/bluez/hci0 org.bluez.Adapter1 Powered` → `b true`
and a fresh quickshell instance reads `enabled=true`. So the switch reads OFF while the radio is on,
and clicking it calls `omarchy-bluetooth-power on` — a no-op — which is what "the switch cannot be
switched" looks like. It is intermittent, matching the "it worked for a while" reports.

## Suggested fix

Read on/off from the rfkill-backed helper rather than `adapter.enabled` (it already answers
`omarchy-bluetooth-power is-on`, and `toggle` decides the direction from the radio), keep the widget
visible when the adapter is absent, and drop the `if (!adapter) return`.

I verified this locally as a cloned widget (`omarchy plugin clone omarchy.bluetooth`): with a 2 s
poll of `omarchy-bluetooth-power is-on` driving the icon/switch and the helper doing the toggling,
off → on works and the widget stays on the bar in both states.

## System

- Omarchy 4.0.3-1, Omarchy (Arch), kernel 7.1.8-arch1-3
- bluez 5.87-2, bluez-utils 5.87-2
- quickshell 0.3.0 (quickshell-git 0.3.0.r20.g28771c7-3, AUR)
- Hyprland 0.56.2, qt6-base 6.11.2-3
- Intel i3-4030U / Haswell-ULT, adapter `hci0` (`F8:16:54:28:2F:D4`)

`omarchy debug` is not usable here: it is listed in `omarchy --help` but the dispatcher answers
`Unknown Omarchy command: omarchy debug` and there is no `omarchy-debug` binary in
`$OMARCHY_PATH/bin`, so no diagnostic log could be generated.