## What happened

The Bluetooth bar widget (`omarchy.bluetooth`) intermittently gets stuck showing the adapter as hidden or "TURNED OFF" even though the adapter is actually powered on at the BlueZ/D-Bus level. It self-corrects after restarting the shell (`omarchy restart shell`) — sometimes needing two restarts in a row.

## Expected behavior

The widget should reliably reflect the adapter's real power state at all times, including right after a shell restart, without needing a second restart.

## Steps to reproduce

This was hard to pin down to a fully deterministic repro. What triggered it once:

1. System had been running for ~2 weeks with Bluetooth powered on the whole time (`bluetoothctl show` reporting `Powered: yes` consistently).
2. The Bluetooth bar widget was not visible in the bar at all.
3. Ran `omarchy restart shell` — the widget appeared, but showed "TURNED OFF" with the toggle switch off.
4. Ran `omarchy-bluetooth-power on` from the command line — `bluetoothctl show` confirmed `Powered: yes` — but the panel still showed "TURNED OFF" and the UI toggle did nothing.
5. Ran `omarchy restart shell` a second time — the widget now correctly showed "ON" and the toggle/scan worked normally.

## Investigation notes

- The widget (`shell/plugins/panels/bluetooth/Panel.qml`) binds directly to Quickshell's own `Quickshell.Bluetooth` module (`Bluetooth.defaultAdapter`, `adapter.enabled`) — this part of Omarchy's code looks correct; it's a plain reactive QML binding.
- I ran a fresh `quickshell` instance with `--log-rules "quickshell.bluetooth*=true;quickshell.dbus.properties*=true"` to watch the underlying D-Bus traffic. In that controlled run, a real BlueZ adapter power-off/power-on cycle (via `omarchy-bluetooth-power off` / `on`) was handled correctly: rfkill-blocking causes BlueZ to fully remove and later recreate the `/org/bluez/hci0` adapter D-Bus object, and Quickshell tracked the new object and its `Powered` property changes correctly end-to-end.
- I was **not** able to reproduce the original "restart doesn't pick up an already-`Powered: yes` adapter" symptom under logging — a genuinely fresh `quickshell` process read `Powered: true` correctly on its very first D-Bus round-trip in every test I ran.
- This mismatch suggests the bug may be a race specific to `omarchy restart shell`'s kill-then-relaunch sequence (`quickshell kill -p ... --any-display` followed by relaunch via `hyprctl dispatch`) rather than a deterministic bug in Quickshell's Bluetooth property sync itself — e.g. the new instance starting before the old one has fully released some D-Bus/session state. I don't have a confirmed root cause.

## System info

- Omarchy version: 4.0.0-1 (stable channel)
- Quickshell: 0.3.0.r20.g28771c7-1 (quickshell-git, built 2026-08-10)
- CPU: Intel Core i7-7500U
- GPU: Intel HD Graphics 620 (Kaby Lake-U GT2)
- Bluetooth controller: Intel/generic USB adapter (hci0), works fine at the `bluetoothctl`/D-Bus level throughout

## Note

`omarchy debug --no-sudo --print` does not exist on this installed version (4.0.0-1) — command list has no `debug` subcommand, so I could not attach the standard diagnostic log.