Never notify about pending migrations during an update

The retired omarchy-update-user-notify.path stays loaded in sessions that
started before the update removing it, and pacman writes the migrations
directory mid-transaction, so it fired a critical toast for migrations that
omarchy-migrate was about to apply a step later. Migration 1785095882 stops
that watcher, but migrations run after pacman, so it lands 11 seconds too
late to prevent the toast it exists to retire.

Check the lock omarchy-update holds for its whole pipeline instead of
trusting that no trigger exists. That covers the stale watcher and anything
added later: during an update every pending migration is by definition
already being applied. The check repeats after waiting for the notification
server, which is long enough for an update to start underneath it.

Only this user's runtime directory is read, never the /tmp path the updater
falls back to without XDG_RUNTIME_DIR. A shared lock file belongs to whoever
created it first, so honouring it would let one user silence another user's
notification; a redundant toast is the better failure.

The sleep inhibitor now starts with the lock descriptor closed. It outlives
the step that starts it, so an update killed before restore_update_inhibitors
left it holding the flock indefinitely. That already blocked later updates,
and now that the notifier reads the same lock it would have silenced
migration notices at every login.

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

docs/update-process.md

@@ -163,6 +163,28 @@ transaction inside a normal `omarchy update`, so it fired notifications for
 migrations that `omarchy-migrate` was about to apply in the visible update
 terminal. The retired unit was `omarchy-update-user-notify.path`.
 
+Retiring that watcher through a migration cannot come in time for the update
+that retires it: pacman writes the migration directory, the watcher fires, and
+only then does `omarchy-migrate` reach the migration that stops it. So the
+notifier also refuses to run while `omarchy update` holds its
+`$XDG_RUNTIME_DIR/omarchy-update.lock`, which covers the stale watcher and any
+trigger added later — during an update, every pending migration is by
+definition already being applied a step away. It checks again after waiting for
+the notification server, since that wait is long enough for an update to start
+underneath it.
+
+The notifier reads only its own user's runtime directory, never the `/tmp` path
+`omarchy-update` falls back to when `XDG_RUNTIME_DIR` is unset. A shared lock
+file belongs to whoever created it first, so honouring it would let one user
+silence another user's notification. Missing an update and showing a redundant
+toast is the better failure.
+
+Suppression is why `omarchy-update` starts its sleep inhibitor with the lock
+descriptor closed. That inhibitor outlives the step that starts it, so an update
+killed before `restore_update_inhibitors` would otherwise leave it holding the
+flock indefinitely — blocking later updates and, now that the notifier reads the
+same lock, silencing migration notifications at every login.
+
 Fallbacks:
 
 - `omarchy-first-run` enables `omarchy-migrate-notify.service`, which also