## What happened

After the machine resumes from standby, the paired Bluetooth mouse (Logitech MX Master 3S, `D0:CC:5B:64:79:63`) stops reconnecting. BlueZ still has it as `Paired: yes / Bonded: yes / Trusted: yes / Connected: no`, and `bluetoothctl connect` fails.

`omarchy restart bluetooth` does not fix it. Neither does an adapter power cycle:

```
$ bluetoothctl power off && bluetoothctl power on
$ bluetoothctl connect D0:CC:5B:64:79:63
Attempting to connect to D0:CC:5B:64:79:63
Failed to connect: org.bluez.Error.Failed le-connection-abort-by-local
```

`le-connection-abort-by-local` is the local host aborting the LE connection attempt, so the retry loop never has anything to succeed against. A 20s `bluetoothctl --timeout 20 scan on` finds no advertisements from the mouse, so BlueZ is not simply missing a reconnect window.

Related: omarchy #12095 describes the same user-visible symptom (BLE HID never reconnects after wake) but is specific to Intel controllers autosuspended via the Chromium OS hwdb allowlist. This machine has a Realtek combo adapter, so that analysis does not apply.

## Steps to reproduce

1. Pair a BLE HID mouse (MX Master 3S).
2. Suspend and resume the machine.
3. Try to reconnect the mouse, either by moving it or from the Bluetooth panel.

Also observed on this machine with no standby involved: the mouse stopped advertising altogether and stayed `le-connection-abort-by-local` across repeated `omarchy restart bluetooth` and an adapter power cycle, until the mouse was woken by a button press.

## Suspected area

Not confirmed. The pieces I ruled out on this machine:

- **Not the shipped USB autosuspend fix.** `/etc/modprobe.d/omarchy-usb-autosuspend.conf` contains `options usbcore autosuspend=-1`, and `usbcore` is builtin (`modinfo usbcore` -> `(builtin)`), so the parameter never applies: `/sys/module/usbcore/parameters/autosuspend` still reads `2`. This confirms the inert-file half of #12095 generally, though the controller here is not one the hwdb matches.
- **Not runtime PM on the controller.** `/sys/bus/usb/devices/1-2/power/runtime_status` stayed `active` for the whole time I watched it, despite `power/control=auto` and `power/autosuspend_delay_ms=2000`. So the controller is not asleep while the connect fails.
- **Not a leaked discovery session.** `Adapter1 Discovering` is `false` while idle, and no third-party Bluetooth client is running. (The mechanism reported in #11380, for the record.)
- **Not a blocked radio.** `rfkill` shows `hci0` unblocked in both soft and hard, and `bluetoothctl show` reports `Powered: yes`.

## What I did not do

I did not add any hook, udev rule, or modprobe drop-in. `~/.config/omarchy/hooks/bt-reconnect-mouse.sh` is a leftover from an earlier attempt and is currently installed nowhere (`omarchy hook install` copies into a `<type>.d/` directory, and there is no `.d/` entry for it), so it never runs.

## System details

```
Omarchy:    4.0.4-1
Kernel:     7.2.5-3-omarchy (linux-omarchy)
BlueZ:      5.87-2
CPU:        Intel(R) Core(TM) i5-7500 @ 3.40GHz (Kaby Lake desktop)
GPU:        Intel HD Graphics 630
Bluetooth:  Realtek 0bda:c820 combo adapter, mounted at
            /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0
            MAC 3C:64:CF:8A:59:5B, HCI class 0x006c0104
Mouse:      Logitech MX Master 3S, D0:CC:5B:64:79:63, modalias usb:v046DpB034d0003
CONFIG_BT_HCIBTUSB=m, CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
No TLP, no powertop installed. rfkill: hci0 unblocked, phy0 (wlan) soft-blocked.
```

`omarchy debug --no-sudo --print` from the contributing guide does not exist on 4.0.4 (`omarchy commands --all` has no `debug` subcommand), so the raw outputs above stand in for it.

## Question

Is a Bluetooth-reconnect attempt after resume supposed to be Omarchy's job at all, or is this expected to be handled by BlueZ's passive auto-connect for bonded devices? If it is Omarchy's job, the missing piece seems to be a resume hook that retries `connect` for bonded devices, since the adapter is healthy and the retry currently has nothing to work with.