### System details

- Omarchy 4.0.0-1 (`quattro`), upgraded from 3.8.5 with `omarchy-upgrade-to-quattro` on 2026-08-14 (script at de854d3f, same logic at current quattro HEAD 30471bf3)
- Microsoft Surface Laptop 4, i7-1185G7, Intel Iris Xe, Wayland/Hyprland, fcitx5 via `omarchy-fcitx5.service`
- libxkbcommon 1.x (`xkbcli compile-compose` available)

### What's wrong

After the 3 → 4 upgrade, `~/.XCompose` still reads

```
include "%H/.local/share/omarchy/default/xcompose"
```

(the line the Omarchy 3 installer wrote), and `/etc/udev/rules.d/99-power-profile.rules` + `99-wifi-powersave.rules` still run `omarchy-powerprofiles-set` / `omarchy-wifi-powersave` out of `~/.local/share/omarchy/bin/`. Nothing in the upgrade rewrites them; they only keep working because `cleanup_legacy_user_paths` in `bin/omarchy-upgrade-to-quattro` leaves a compat symlink `~/.local/share/omarchy -> /usr/share/omarchy` behind (the comment describes it as a shim "for the rest of the live session").

Remove that symlink — an obvious cleanup, it sits right next to the 333 MB `~/.local/share/omarchy.omarchy-upgrade-to-quattro.<ts>.bak` of the old checkout — and:

- xkbcommon rejects the **whole** `~/.XCompose` on the failed include, so every CapsLock sequence is dead: emoji *and* the name/email macros the installer added. Every terminal launch logs
  `xkbcommon: ERROR: /home/<user>/.XCompose:4:9: failed to open included Compose file "/home/<user>/.local/share/omarchy/default/xcompose": No such file or directory` / `failed to parse file`, and fcitx5 (same parser) silently loses the sequences too.
- udev logs `Process '/usr/bin/systemd-run ... /home/<user>/.local/share/omarchy/bin/omarchy-powerprofiles-set' failed with exit code 1` on every AC/battery change. (Harmless in practice — the quattro shell switches power profiles itself via `shell/plugins/services/battery/Service.qml` — but it is dead weight the upgrade should have retired, the way it removes `99-uinput.rules` and the Dell XPS rule in `apply_system_transition`.)

There is no error surfaced to the user beyond compose "just not working".

### Steps to reproduce

On any system upgraded from Omarchy 3 with `omarchy-upgrade-to-quattro`:

```bash
sed -n 4p ~/.XCompose
# include "%H/.local/share/omarchy/default/xcompose"
grep -l 'local/share/omarchy' /etc/udev/rules.d/*
# /etc/udev/rules.d/99-power-profile.rules
# /etc/udev/rules.d/99-wifi-powersave.rules

rm ~/.local/share/omarchy            # the compat symlink
xkbcli compile-compose --file ~/.XCompose
# xkbcommon: ERROR: (unknown file):4:9: failed to open included Compose file ...
# ERROR: Couldn't create compose from file
omarchy restart xcompose             # CapsLock space e -> nothing
```

Restore with `ln -s /usr/share/omarchy ~/.local/share/omarchy` (or fix the include).

### Why this is an upgrade gap rather than user error

`apply_user_transition` already rewrites other user files that carried the legacy path — chromium/brave `*-flags.conf` (`repair_chromium_copy_url_extension_flags`), `~/.config/uwsm/env`, walker config, user systemd units (all left as `.omarchy-upgrade-to-quattro.<ts>.bak`) — but skips `~/.XCompose`, which is exactly the file the manual tells users to edit (`manual/31-dotfiles.md`). The XCompose block in the script only writes a fresh file when none exists:

```bash
if [[ ! -f $HOME/.XCompose ]]; then
  cat >"$HOME/.XCompose" <<EOF
  ...
  include "/usr/share/omarchy/default/xcompose"
```

so every upgraded install keeps the legacy include and depends on the symlink forever. Nothing documents that symlink as load-bearing.

### Fix

PR incoming: a migration that repoints the include at `/usr/share/omarchy/default/xcompose` (and reloads fcitx5 when it changed), and removes the two rules when they still point at the legacy checkout. Since `run_post_upgrade_migrations` runs after the user transition, the same migration covers fresh upgrades and systems that upgraded earlier.