`omarchy install service sunshine` can never complete. The script enables the Sunshine user unit by its **alias** name, which systemd rejects in both possible states, and because the script runs under `set -e` the failure silently skips every remaining install step.

## The bug

`bin/omarchy-install-service-sunshine` does:

```bash
omarchy-pkg-add sunshine
systemctl --user enable --now sunshine
```

But the Arch `sunshine` package ships exactly one unit:

```
/usr/lib/systemd/user/app-dev.lizardbyte.app.Sunshine.service
```

whose `[Install]` section declares `Alias=sunshine.service`. A systemd `Alias=` symlink is created *by* `enable` — it does not exist beforehand. That gives two states, and `enable --now sunshine` fails in both:

| alias symlink | result |
|---|---|
| absent (fresh install) | `Failed to enable unit: Unit sunshine.service does not exist` |
| present (after enabling the real name) | `Failed to enable unit: Refusing to operate on linked unit file sunshine.service` |

Once the alias exists at `~/.config/systemd/user/sunshine.service`, systemd classifies it as a *linked* unit and refuses to enable by that name. So re-running the command after a partial install does not recover it either.

## Why it's worse than one error line

The script is `set -e`, so the failed `enable` aborts everything after it:

- ufw rules for the Moonlight ports (47984/47989/48010 tcp, 5353/47998/47999/48000/48002/48010 udp)
- the "Sunshine Admin" webapp entry
- the `o.launch_on_start("sunshine")` line in `~/.config/hypr/autostart.lua`

The user sees a single `Failed to enable unit` line after a successful-looking pacman transaction, and is left with a package installed, no service, no firewall rules, and no launcher entry — with no indication that three further steps were skipped.

## Reproduce

On a machine without sunshine installed:

```bash
omarchy install service sunshine
```

Observe `Failed to enable unit: Unit sunshine.service does not exist` as the last line, then:

```bash
systemctl --user is-enabled app-dev.lizardbyte.app.Sunshine.service   # disabled
sudo ufw status | grep -c omarchy-sunshine                            # 0
ls ~/.local/share/applications | grep -i sunshine                     # nothing
```

## Suggested fix

Enable the real unit name; the alias is then created as a side effect:

```diff
-systemctl --user enable --now sunshine
+systemctl --user enable --now app-dev.lizardbyte.app.Sunshine.service
```

Worth noting separately: with uwsm running, `graphical-session.target` is active and the unit is `WantedBy=graphical-session.target`, so it already autostarts at login. The `o.launch_on_start("sunshine")` line the script adds to `autostart.lua` starts a second instance on top of the systemd one. That may be deliberate belt-and-braces for non-uwsm setups, but on a default Omarchy 4 install it looks redundant.

## System

- Omarchy 4.0.1-1
- sunshine 2026.516.143833-4 (omarchy repo)
- systemd 261 (261.2-1-arch)
- kernel 7.1.9-arch1-2

Verified fixed locally by enabling `app-dev.lizardbyte.app.Sunshine.service` directly and then running the skipped steps by hand.

---

Filed by Claude Opus 5 via Claude Code.