## What happened

`omarchy update` on `omarchy-dev 4.0.0.r2304.g7b336b1-1` asks for the sudo password once per `sudo` call. A run on 2026-09-26 at 07:28 (`/tmp/omarchy-update.log`) asked four times and never finished:

1. `paccache` under "Prune package cache"
2. `snapper --csvout list-configs` (this prompt is printed before "Create system snapshot")
3. `snapper create`
4. `snapper cleanup`

The log ends on that fourth prompt. `script` never wrote a footer.

## Expected

One password covers the fixed helpers: prune, snapshot, keyring, pacman, orphan removal, and service restart. Phases that run third-party or user code (migrations, AUR builds, post-update hooks, mise) authenticate with `sudo --no-update`, so a successful prompt does not publish a reusable timestamp.

## Cause

`bin/omarchy-update` revokes the sudo timestamp, then puts `default/omarchy/sudo-no-update/sudo` first on `PATH` for the whole run. The wrapper execs `/usr/bin/sudo -N`. `--no-update` authenticates and does not write a timestamp, so the next `sudo` has nothing to reuse.

That behavior is commit `35b318ed` ("Complete command-scoped authentication across update phases"), carried in by #9469, and it is what r2304 runs. #9469's finding is narrower: keep hooks, AUR builds, mise, and channel hooks outside authorization the update itself creates.

## Validation of #13268

#13268 describes this failure correctly. Stopping the global wrapper install would collapse the four prompts above into one, because nothing between prune and snapshot clears the timestamp.

The patch is not a sufficient fix. Checked against the r2304 scripts and the pull request diff:

1. `omarchy-update-stay-awake start` sits in the middle of the span the pull request treats as one authorization. The script runs `sudo -k` on entry, starts the inhibitor with `/usr/bin/sudo -N -b`, and runs `sudo -k` again from its exit trap. Those clears are account-wide. The ticket saved by prune and snapshot dies there, the inhibitor's own prompt is not cached, and the next helper (keyring or pacman) prompts again. The diff does not change this script.

2. The cold boundary moves to just before AUR, so `omarchy-migrate` runs with a normal caching `sudo`. The pull request's own doc edit still says historical migrations mix user-controlled code with later privileged repairs. On r2304, 40 migrations call `sudo`. These run mise or install a hook while that cache would be live and refreshed by every successful `sudo`: `migrations/1789095456.sh`, `migrations/1789310715.sh`, `migrations/1789764927.sh`, `migrations/1790017600.sh`. That is the reuse #9469 closed.

3. The test change in `test/shell.d/update-hook-security-test.sh` stubs the steps and asserts that no `sudo -N` line appears before `yay`. It does not run `omarchy-update-stay-awake` or `omarchy-migrate`, so both holes stay green.

A fix that holds keeps caching `sudo` for prune, snapshot, keyring, pacman, orphan removal, and service restart. Stay-awake must leave a timestamp alone when it did not create one. `sudo -k` and the no-update wrapper go on at `omarchy-migrate` and stay on through AUR, hooks, and mise. On an already-migrated machine that is one password for the system update, then a separate prompt only if an untrusted phase needs root.

## System details

- Omarchy: `4.0.0.r2304.g7b336b1-1` (`omarchy-dev`, quattro)
- CPU: Intel Core Ultra X7 358H
- GPU: Intel Arc B390 (Panther Lake, 8086:b080)
- sudo: 1.9.17p2
- `sudo -n -l` grants `NOPASSWD` only for `asdcontrol`, `omarchy-dns`, `omarchy-theme-set-browser-policy`, and a `timedatectl` timezone pattern. pacman, snapper, and paccache require a password.