openlogi-agent racing kernel hci0 bring-up at login causes HCI command timeouts / dead Bluetooth adapter (Linux)

## Summary

On Linux, `openlogi-agent` starts via its packaged user unit (`After=graphical-session.target`, no ordering against Bluetooth) at login. On this machine that lands at almost exactly the same moment the kernel is bringing up the Bluetooth USB controller (firmware load, `HCI Reset`, etc.). The two race, and the adapter's HCI commands start timing out and never recover for the rest of the boot — `bluetoothd` shows "No default controller available" even though `hci0` exists in `/sys/class/bluetooth/`.

Restarting `bluetooth.service` does **not** fix it. The only recovery I found was forcing a full USB re-enumeration of the adapter (`echo 0/1 > /sys/bus/usb/devices//authorized`) while `openlogi-agent` was stopped.

## Environment

- Distro: Omarchy (Arch-based), `BUILD_ID=4.0.1` (latest RC)
- Kernel: `7.1.9-arch1-2`
- Package: `openlogi-bin v0.8.1-1`
- Bluetooth/WiFi combo: MediaTek MT7921 (Filogic 330) — WiFi via `mt7921e` (PCIe), Bluetooth via `btusb` (USB, `13d3:3563`)
- `bluez` 5.87

## Evidence

`journalctl -k -b` at boot:

```
Aug 27 08:10:48 kernel: Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224111243
Aug 27 08:10:48 kernel: Bluetooth: hci0: Device setup in 129557 usecs
Aug 27 08:10:50 kernel: Bluetooth: hci0: Opcode 0x0c03 failed: -110
```

`openlogi-agent` (user unit) starting seconds later, at the same boot:

```
Aug 27 08:10:56 systemd[1403]: Started OpenLogi background agent (Logitech HID++ device control).
Aug 27 08:10:56 openlogi-agent[2148]: openlogi_agent: openlogi-agent started
```

Once this race happens, `bluetoothctl show` reports `No default controller available` for the rest of the session, and `rfkill` shows the adapter as unblocked the whole time (so it's not an rfkill issue).

Reproduced the recovery/root-cause by:
1. `systemctl --user stop openlogi-agent`
2. Force a USB re-enumeration of the Bluetooth controller: `echo 0 > /sys/bus/usb/devices/3-3/authorized; sleep 2; echo 1 > /sys/bus/usb/devices/3-3/authorized`
3. Bluetooth comes back up cleanly (`bluetoothctl show` reports a working, powered controller)
4. `systemctl --user start openlogi-agent` again — stays working, since the kernel-side HCI bring-up had already completed before openlogi grabbed devices this time.

Doing step 2 alone (without stopping openlogi-agent first) did **not** reliably fix it — it seems to depend on whether openlogi-agent is actively probing/holding a HID++ session at the moment the adapter re-initializes.

## Suggested fix

The packaged systemd user unit (`/usr/lib/systemd/user/openlogi-agent.service`) has no dependency on Bluetooth being ready:

```
[Unit]
Description=OpenLogi background agent (Logitech HID++ device control)
After=graphical-session.target
```

Since user units can't natively order against system units (`bluetooth.service`) via `After=`, a startup guard that waits for `/sys/class/bluetooth/hci0` to exist (plus a short settle delay) before openlogi starts probing devices would avoid this race. I've applied that as a local drop-in override and it resolves the issue for me:

```ini
[Service]
ExecStartPre=/usr/bin/bash -c 'for i in $(seq 1 20); do [ -e /sys/class/bluetooth/hci0 ] && sleep 3 && exit 0; sleep 0.5; done'
```

Happy to provide more logs/details if useful.

Start with /usr/lib/systemd/user/openlogi-agent.service and review how its graphical-session ordering interacts with Bluetooth initialization on Linux. Reproduce the login race using the journalctl and bluetoothctl evidence in the report, then evaluate the proposed startup guard and its behavior when hci0 appears late. Done means the agent starts without causing HCI timeouts and Bluetooth remains available after login.

Written by the indexing model from the issue text.