_Note: issue reported by AI._

## What happened

After the Quattro migration, `bt-agent.service` restart-loops forever
(every 2s, indefinitely — 668 restarts in the first 25 minutes of a boot on
my machine):

    bt-agent.service: Unable to locate executable '/usr/bin/bt-agent': No such file or directory
    bt-agent.service: Failed at step EXEC spawning /usr/bin/bt-agent: No such file or directory
    bt-agent.service: Main process exited, code=exited, status=203/EXEC
    bt-agent.service: Failed with result 'exit-code'.
    (repeats forever)

## Root cause (traced through my own pacman.log + the migration script)

`/usr/bin/bt-agent` is provided by `bluez-tools`, not `bluez-utils`. On my
machine `omarchy-upgrade-to-quattro` ran a transaction that:

1. Installed `bluetui`
2. Removed `blueberry` via `pacman -Rns`, which cascaded and removed
   `gnome-bluetooth` and `bluez-tools` as now-orphaned dependencies
   (`bluez-tools` was never installed for its own sake — it came in
   transitively via blueberry/gnome-bluetooth)
3. Later in the same script, `enable_user_unit bt-agent.service`
   (bin/omarchy-upgrade-to-quattro, retiring
   `systemd/user/bt-agent.service` -> `/usr/lib/systemd/user/bt-agent.service`,
   shipped by `omarchy-settings`)

`omarchy-settings` does not depend on `bluez-tools`:

    $ pacman -Qi omarchy-settings | grep Depends
    Depends On      : bash  curl  gum  hicolor-icon-theme  plymouth

So the same migration that retires blueberry (bt-agent's last remaining
dependent) also turns on a unit that requires the binary blueberry was
providing indirectly, with nothing left to guarantee it's still installed.
Anyone who goes through this migration and doesn't happen to have
`bluez-tools` pulled in by something else ends up with a permanently
crash-looping user unit.

## Expected

Either:
- `omarchy-settings` should depend on `bluez-tools` (or whatever package
  currently provides `bt-agent` upstream), or
- `bt-agent.service` should have an `ExecCondition` that fails cleanly when
  the binary is missing, the way the neighboring bluetooth condition
  (`ExecCondition=systemctl is-active --quiet bluetooth.service`) already
  does for the "no adapter" case.

## Possible side effect (correlation, not proven)

While investigating this I was actually chasing an unrelated
`sway-audio-idle-inhibit` crash (aborts by design on any D-Bus error talking
to logind — that part is a bug in that upstream AUR project, not Omarchy).
All of that program's crashes on my machine landed inside one of these
`bt-agent.service` restart-loop windows, which touch the system D-Bus every
2 seconds. I can't prove the loop caused the D-Bus hiccup, but it's a
plausible mechanism and seems worth mentioning in case others hit the same
combination.

## System

- Omarchy 4.0.0-1
- Kernel 7.1.8-arch1-3