### System details

- Omarchy 4.0.1-1, Hyprland 0.56.2, libxkbcommon 1.13.2-1, steam 1.0.0.87-3
- AMD Ryzen 7 7800X3D, NVIDIA RTX 4090 (+ Raphael iGPU), Wayland/Hyprland, fcitx5 via `omarchy-fcitx5.service`

### What's wrong

`install/user/xcompose.sh` writes `~/.XCompose` with an **absolute** include into the packaged tree:

```bash
tee ~/.XCompose >/dev/null <<EOF
# Run omarchy-restart-xcompose to apply changes

# Include fast emoji access
include "/usr/share/omarchy/default/xcompose"
...
EOF
```

Steam runs games inside pressure-vessel, a container with its own `/usr`. `$HOME` is bind-mounted into it, so the container reads `~/.XCompose` — but `/usr/share/omarchy` does not exist there, so the include cannot resolve.

A failed include does not degrade gracefully. It aborts the whole compose table:

```
$ xkbcli compile-compose --file /tmp/bad.compose
xkbcommon: ERROR: (unknown file):1:9: failed to open included Compose file "/usr/share/omarchy/does-not-exist"
xkbcommon: ERROR: (unknown file):1:9: failed to parse file
ERROR: Couldn't create compose from file: /tmp/bad.compose
$ echo $?
1
```

So inside Steam and every Proton game, **no** compose sequence works — not the Omarchy emoji shortcuts, not the identity macros, not the `%L` locale defaults. Each affected process also logs the failure to the journal:

```
steam[80717]: xkbcommon: ERROR: /home/<user>/.XCompose:4:9: failed to open included Compose file
              "/usr/share/omarchy/default/xcompose": No such file or directory
steam[80717]: xkbcommon: ERROR: /home/<user>/.XCompose:4:9: failed to parse file
```

Confirmed the container genuinely cannot see the path, while it can see the file that references it:

```
$ ls /proc/$(pgrep -f SomeGame.exe)/root/usr/share/omarchy/default/xcompose
ls: cannot access '...': No such file or directory
$ ls /proc/$(pgrep -f SomeGame.exe)/root/home/<user>/.XCompose
-rw-r--r-- 1 <user> <user> 232 Aug 30 15:18 /proc/.../.XCompose
```

The same reasoning applies to any sandboxed app that sees `$HOME` but not the host `/usr` — Flatpaks, for instance — though I only verified Steam/pressure-vessel.

### This is a regression from Omarchy 3

Per #8173, Omarchy 3 wrote:

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

`%H` expands to `$HOME`, which **is** bind-mounted into the container, so the Omarchy 3 form resolved correctly inside Steam. Moving the include to an absolute `/usr/share/omarchy` path is what broke it.

Worth flagging against #8175, which proposes repointing `~/.XCompose` at the packaged tree to fix the quattro upgrade path: as written that would give upgraded installs the same absolute include, and with it this bug.

### Steps to reproduce

1. Fresh Omarchy 4 install (or any install whose `~/.XCompose` has the absolute include).
2. Launch any Steam game, native or Proton.
3. Try a compose sequence in-game, e.g. CapsLock `m` `s`. Nothing is produced.
4. `journalctl --user -b | grep xkbcommon` shows the parse errors above.

### Suggested fix

Make the include home-relative so it resolves inside containers, writing a copy into `$HOME` at install time:

```bash
cp /usr/share/omarchy/default/xcompose ~/.XCompose.omarchy
# in ~/.XCompose:
include "%H/.XCompose.omarchy"
```

That keeps the packaged file authoritative at install/update time while leaving `~/.XCompose` self-contained from a container's point of view. It needs a re-sync step on update, which the current absolute include avoids — so if keeping the packaged path is preferred, the alternative is to accept that compose is simply unavailable in sandboxed apps and drop the include from the generated file rather than emit one that fails to parse.

### Note

I found this while chasing an unrelated missing-keyboard-input problem in a Proton game. Fixing this did **not** resolve that, and I want to be clear I have no evidence the broken include causes loss of key input — the verified impact is dead compose sequences plus journal error spam in every Steam/Proton process.