Only check for pending migrations at login

omarchy-update-user-notify.path watched /usr/share/omarchy/migrations, but
pacman writes that directory during every update, including the blessed
omarchy update, which runs omarchy-migrate a step later. The watcher fired a
critical notification for the migrations the update was already applying in
the visible terminal. A watcher cannot tell that apart from a bypassed
pacman -Syu, so the only trigger that never collides with a running update is
a once-per-login check.

The service that already ran at graphical-session.target is now the whole
mechanism, renamed after the command it runs. That is also all the second-user
case needs: markers are per-user, so anyone who did not run the update finds
them missing at their next login.

Login timing means the toast can be sent before the shell has claimed
org.freedesktop.Notifications, so the notifier waits for a live server first.
The wait is omarchy-first-run's, lifted into omarchy-notification-wait rather
than duplicated.

The package keeps omarchy-update-user-notify.service as a symlink onto the new
unit. Existing users hold an absolute wants symlink to the old path, and the
migration that repoints it only runs for users who run an update, which is the
opposite of who the notifier is for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/file-layout.md

@@ -197,13 +197,19 @@ migration. Migrations run as the user; privileged work should invoke the
 appropriate helper or privilege prompt. Migrations must be idempotent;
 machine-wide repairs should no-op when another user already applied them.
 
-Each graphical user has `omarchy-update-user-notify.path` watching the packaged
-migration directory for changes, and `omarchy-update-user-notify.service` is
-also started once per login via its own `WantedBy=graphical-session.target`.
-Either way the service runs `omarchy-migrate-notify` as that user. The notifier checks
-`omarchy-migrate --pending`. If this user has missing migration state, it shows a
-notification that opens a terminal for `omarchy-migrate`. The notifier never runs
-migrations in the background.
+Each graphical user has `omarchy-migrate-notify.service`, started once per login
+through `WantedBy=graphical-session.target`. The package also ships
+`omarchy-update-user-notify.service` as a symlink onto it, so users enabled
+under the old unit name keep working before they reach migration `1785095882`.
+It runs `omarchy-migrate-notify` as
+that user, which checks `omarchy-migrate --pending`. If this user has missing
+migration state, it shows a notification that opens a terminal for
+`omarchy-migrate`. The notifier never runs migrations in the background.
+
+Login is the only trigger. Nothing watches the packaged migration directory: a
+watcher cannot tell a bypassed `pacman -Syu` from the package transaction inside
+a normal `omarchy update`, so it notified about migrations that `omarchy-migrate`
+was already applying in the visible update terminal.
 
 `omarchy-migrate` waits for any active pacman transaction to finish, then runs
 pending migrations. It does not need `--force`; migrations happen when state
@@ -221,8 +227,8 @@ systemd instance:
   Voxtype post-update hook.
 - `install/user/first-run/enable-user-units.sh` — `systemctl --user enable`
   the shipped user units (`bt-agent`, `omarchy-sleep-lock`,
-  `omarchy-recover-internal-monitor`, `omarchy-update-user-notify.path`,
-  `omarchy-update-user-notify.service`). Done here, not at finalize, because
+  `omarchy-recover-internal-monitor`, `omarchy-migrate-notify.service`).
+  Done here, not at finalize, because
   the user manager isn't reachable from the ISO chroot; `ConditionPath*`
   in the unit files keeps services inert when they don't apply.
 - `install/user/first-run/gnome-theme.sh`,