## What happened

Running the official `omarchy restart hyprsunset` (or `omarchy-restart-hyprsunset`) kills the running hyprsunset and ends with **no hyprsunset process at all**. The replacement launched by `omarchy-restart-app` via `setsid uwsm-app -- hyprsunset &` dies within seconds, silently (no error in the command output, nothing in the user journal).

This matters more than a plain crash because hyprsunset reads `~/.config/hypr/hyprsunset.conf` **only at startup**: users who edit the night-light temperature (or any profile) and restart to apply it end up with either a dead night light or a stale-tinted screen, and no visible error anywhere. It looks exactly like "my config change doesn't work / reverted".

## Steps to reproduce

```
pgrep -a hyprsunset                     # e.g. 412508 hyprsunset — running
omarchy-restart-hyprsunset
sleep 2
pgrep -a hyprsunset                     # -> (empty)
```

Journal shows the replacement starting and then vanishing with no error:

```
uwsm_app-daemon[1228]: received: app -- hyprsunset
uwsm_app-daemon[1228]: sent: exec systemd-run --user --scope --slice=app-graphical.slice --unit=app-Hyprland-hyprsunset-8ff5fc60.scope --quiet --collect --same-dir -- hyprsunset
systemd[977]: Started hyprsunset.
# ... process gone seconds later, no stop/error line anywhere
```

The same death pattern hits every launch through the `uwsm-app` client when the launching context exits (which `omarchy-restart-app` always does, being a script that backgrounds and returns): three `app-Hyprland-hyprsunset-*.scope` instances started and disappeared within one debugging session, while a hyprsunset started **outside** uwsm (`pkill -x hyprsunset; setsid hyprsunset >/dev/null 2>&1 &`) survived two days of suspend/resume cycles.

## Expected

`omarchy-restart-hyprsunset` should leave a working hyprsunset running with the current config.

## Root cause (hypothesis)

`omarchy-restart-app` relaunches background daemons through the `uwsm-app` client, whose daemon wraps the app in `systemd-run --user --scope`. The scope appears to be torn down when the short-lived `uwsm-app` client process goes away — which is immediately, since `omarchy-restart-app` backgrounds it and exits. For a long-running daemon like hyprsunset this wrapper is the wrong lifetime model; a plain `setsid` exec (or a proper long-lived `systemd-run --user --unit=...` service) is what sticks.

## Workaround

```
pkill -x hyprsunset
setsid hyprsunset >/dev/null 2>&1 &
```

## System

- Omarchy: dev (83881e97)
- hyprsunset 0.4.0-3, Hyprland 0.56.2-1, quickshell 0.3.1-1
- Kernel: 7.1.9-arch1-2
- AMD Ryzen 5 5500U, Lucienne iGPU