### What happened

On the dev channel, `omarchy update` aborts at migration `1790344599.sh`:

```
Running migration (1790344599)
Require approval for new Thunderbolt accessories
Created symlink '/etc/systemd/system/multi-user.target.wants/omarchy-thunderbolt-authorization.service' -> '/etc/systemd/system/omarchy-thunderbolt-authorization.service'.
Failed to enable unit: Unit omarchy-thunderbolt-authorization.service does not exist

Something went wrong during the update!
```

Because migrations run under `bash -euo pipefail` from `omarchy-migrate` and `omarchy-update` has an `ERR` trap, this single failure aborts the entire update and leaves every later migration pending. In my case `1790608617` (USB approval repair) and `1791542175` (Gliff) only ran after applying the workaround below.

### Root cause

`bin/omarchy-setup-security-thunderbolt-authorization` ends with:

```bash
systemctl --user enable --now omarchy-thunderbolt-authorization.service
```

but the user unit is never installed anywhere systemd can find it:

- `default/systemd/user/omarchy-thunderbolt-authorization.service` exists in the repo (added in 60d6b255d).
- The `omarchy-settings` / `omarchy-settings-dev` PKGBUILDs in omarchy-pkgs install only `bt-agent`, `omarchy-sleep-lock`, `omarchy-recover-internal-monitor`, `omarchy-migrate-notify`, `omarchy-tailscale-receive`, `omarchy-fcitx5` and `omarchy-crash-watch` into `/usr/lib/systemd/user/`. The Thunderbolt unit is missing from both install lists.
- The `package_defaults` fixture in `test/shell.d/config-test.sh` also omits it, so the packaging test does not catch the omission.
- Unlike the USB equivalent (`bin/omarchy-setup-security-usb-authorization`, which copies `default/systemd/user/omarchy-usb-authorization.service` to `~/.config/systemd/user/`), the Thunderbolt setup does not copy its unit anywhere.

`install/user/first-run/enable-user-units.sh` has the same expectation: it enables `omarchy-usb-authorization.service` and `omarchy-thunderbolt-authorization.service` as if they were shipped to a systemd-visible path.

Verified on `omarchy-dev 4.0.0.r6856.g6126321-1`:

```
$ ls /usr/lib/systemd/user/omarchy-thunderbolt-authorization.service
ls: cannot access '/usr/lib/systemd/user/omarchy-thunderbolt-authorization.service': No such file or directory

$ systemctl --user enable --now omarchy-thunderbolt-authorization.service
Failed to enable unit: Unit omarchy-thunderbolt-authorization.service does not exist
```

(matching the message in the update log).

### Steps to reproduce

1. On the dev channel, take a machine where migration `1790344599` still has to run (no marker in `~/.local/state/omarchy/migrations/`).
2. Run `omarchy update`.
3. The update aborts at migration `1790344599` with `Failed to enable unit: Unit omarchy-thunderbolt-authorization.service does not exist`.

### Expected

The migration completes and the watcher unit is enabled, as intended on a freshly installed system.

### Workaround

```bash
install -Dm644 /usr/share/omarchy/default/systemd/user/omarchy-thunderbolt-authorization.service ~/.config/systemd/user/
systemctl --user daemon-reload
omarchy update
```

### System details

- Omarchy Package: `omarchy-dev 4.0.0.r6856.g6126321-1` (dev channel; also reproduced on `4.0.0.r6818.gc352b62-2`)
- CPU: AMD Ryzen 7 5700U
- GPU: AMD Lucienne (Radeon)
- Kernel: 7.2.8-5-omarchy-bore · Hyprland 0.56.2 · Wayland
- Full debug log (expires in 24h): https://logs.omarchy.org/qqX7Nx