`omarchy-settings` ships `omarchy-brightness-keyboard-auto.service` into `/usr/share/omarchy/default/systemd/user/` but never installs it into `/usr/lib/systemd/user/`, unlike the other seven user units. Because the unit does not exist in any systemd unit search path, both the first-run enable and the migration that were meant to turn it on fail.

The blast radius is larger than the keyboard backlight: `install/user/first-run/enable-user-units.sh` enables all seven units in a **single** `systemctl --user enable --now` call under `set -euo pipefail`. systemctl validates the whole list before applying, so one missing unit makes it enable **nothing** and abort the script. Every omarchy user unit was therefore left `disabled` and `inactive` on this machine.

## What happened

```
$ systemctl --user is-enabled omarchy-brightness-keyboard-auto.service
not-found

$ for u in bt-agent omarchy-recover-internal-monitor omarchy-sleep-lock \
           omarchy-migrate-notify omarchy-fcitx5 omarchy-crash-watch; do
    printf "%-38s enabled=%-10s active=%s\n" "$u" \
      "$(systemctl --user is-enabled $u.service)" \
      "$(systemctl --user is-active $u.service)"
  done
bt-agent                               enabled=disabled   active=inactive
omarchy-recover-internal-monitor       enabled=disabled   active=inactive
omarchy-sleep-lock                     enabled=disabled   active=inactive
omarchy-migrate-notify                 enabled=disabled   active=inactive
omarchy-fcitx5                         enabled=disabled   active=inactive
omarchy-crash-watch                    enabled=disabled   active=inactive
```

So bluetooth pairing, sleep lock, crash watch, fcitx5 input method and internal-monitor recovery had never started on this install either. (Both of the above were captured before applying the workaround at the end of this report.)

That systemctl enables nothing when one unit in the list is missing is easy to confirm directly:

```
$ systemctl --user enable --now bt-agent.service does-not-exist.service
Failed to enable unit: Unit does-not-exist.service does not exist
$ systemctl --user is-enabled bt-agent.service
disabled
```

## What was expected

The keyboard backlight follows the ambient light sensor, and the other six user units are enabled and running, as `enable-user-units.sh` intends.

## Root cause

The package installs eight units to the systemd path, omitting this one:

```
$ pacman -Ql omarchy-settings | grep 'systemd/user/.*\.service'
omarchy-settings /usr/lib/systemd/user/bt-agent.service
omarchy-settings /usr/lib/systemd/user/omarchy-crash-watch.service
omarchy-settings /usr/lib/systemd/user/omarchy-fcitx5.service
omarchy-settings /usr/lib/systemd/user/omarchy-migrate-notify.service
omarchy-settings /usr/lib/systemd/user/omarchy-recover-internal-monitor.service
omarchy-settings /usr/lib/systemd/user/omarchy-sleep-lock.service
omarchy-settings /usr/lib/systemd/user/omarchy-tailscale-receive.service
omarchy-settings /usr/lib/systemd/user/omarchy-update-user-notify.service
omarchy-settings /usr/share/omarchy/default/systemd/user/omarchy-brightness-keyboard-auto.service   # <- only here
```

`migrations/1788139121.sh` did run, but could not recover:

- Its `systemctl --user enable omarchy-brightness-keyboard-auto.service` fails with `Unit ... not found`.
- Its fallback writes a `.wants` symlink pointing at `/usr/lib/systemd/user/omarchy-brightness-keyboard-auto.service`, which does not exist — a dangling link.

This is not hardware-gated. The unit's `ExecCondition` passes here: the ALS (`aop-sensors-als`, `in_illuminance_input`) and the LED (`/sys/class/leds/kbd_backlight`, max 255) are both present, and `omarchy-brightness-keyboard-auto --available` exits 0. Manual `omarchy-brightness-keyboard up` and the `SHIFT + XF86MonBrightness*` binds work correctly, so only the automatic path is affected.

## Steps to reproduce

1. Install Omarchy 4.0.2 on hardware with an ALS and a keyboard backlight LED.
2. `systemctl --user is-enabled omarchy-brightness-keyboard-auto.service` → `not-found`.
3. Check the other six units from `enable-user-units.sh` → all `disabled`.
4. In a dark room the keyboard backlight stays off.

## Suggested fix

1. Install `omarchy-brightness-keyboard-auto.service` to `/usr/lib/systemd/user/` in the package, as with the other units.
2. Make `enable-user-units.sh` resilient so one missing unit cannot silently disable the rest — enable units individually, or drop `set -e` around that call:

```bash
for unit in "${units[@]}"; do
  systemctl --user enable --now "$unit" || echo "warning: could not enable $unit" >&2
done
```

## Workaround

```bash
ln -sfn /usr/share/omarchy/default/systemd/user/omarchy-brightness-keyboard-auto.service \
  ~/.config/systemd/user/omarchy-brightness-keyboard-auto.service
systemctl --user daemon-reload
systemctl --user enable --now omarchy-brightness-keyboard-auto.service
```

Symlinking the package-owned file rather than copying it into `/usr/lib/systemd/user/` avoids a pacman "file exists in filesystem" conflict on the next update. The other six units then need enabling by hand, one at a time. Verified across a reboot: all seven now start from a cold boot, with `omarchy-migrate-notify` and `omarchy-recover-internal-monitor` correctly finishing as `inactive`/`success` (both are `Type=oneshot`).

## System details

| | |
|---|---|
| Omarchy version | 4.0.0.alpha (`omarchy-settings 4.0.2-1`, repo `omarchy-aarch64`) |
| Model | MacBook Air M2 — `Mac14,2`, `apple,j413`, `apple,t8112` |
| CPU | Apple M2 (aarch64) |
| Kernel | 7.1.6-1-1-ARCH aarch64 |
| Hyprland | 0.56.2 |
| ALS | `aop-sensors-als` (`in_illuminance_input`) |
| Keyboard LED | `/sys/class/leds/kbd_backlight`, max_brightness 255 |

`omarchy debug --no-sudo --print` is referenced in the contributing docs but is not a command in this version (`omarchy commands --all` lists no debug entry), so the details above were collected manually.