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/migrations.md

@@ -43,16 +43,9 @@ omarchy-hook post-update
 `omarchy-migrate` waits for any active pacman transaction to finish, then runs
 all pending migrations for the current user in the visible update terminal.
 
-### During direct pacman updates
+### At login
 
-Raw `sudo pacman -Syu` is guarded. Users should normally run:
-
-```bash
-omarchy update
-```
-
-If a user explicitly bypasses the guard, user sessions watch the packaged
-migration directory and run a notifier. The notifier checks:
+Every graphical login starts `omarchy-migrate-notify.service`, which checks:
 
 ```bash
 omarchy-migrate --pending
@@ -67,6 +60,15 @@ omarchy-migrate
 
 The notifier never runs migrations silently in the background.
 
+This is what covers users who did not run the update themselves: someone who
+bypassed the pacman guard with `sudo env OMARCHY_ALLOW_DIRECT_PACMAN=1 pacman
+-Syu`, and any second user on the machine, whose migration markers are per-user
+and therefore still missing after another user updated.
+
+Login is the only trigger on purpose. Watching the packaged migration directory
+also fires during a normal `omarchy update`, which prompts for migrations that
+`omarchy-migrate` is about to run in the visible update terminal.
+
 ### Manually
 
 Users can safely run: