### What happens

`omarchy sudo passwordless` writes a `NOPASSWD: ALL` sudoers drop-in, so the user should not be prompted.
But `omarchy update` still stops on `[sudo] password for <user>:` and, with no one at the keyboard, hangs
until the prompt times out and `set -e` aborts the run.

The abort happens **after the pre-update snapshot has been taken**, so the machine is left having done the
risky half of the operation and none of the useful half. On an unattended box (CI, a server, a VM driven by
an agent) this is a silent five-minute stall followed by a failed update.

### Cause

`bin/omarchy-update-stay-awake`, in the `systemd-inhibit` branch:

```bash
if omarchy-cmd-present systemd-inhibit; then
  if (( EUID != 0 )); then
    if [[ -t 0 ]]; then
      sudo -v                    # ← line 95
      inhibit_runner=(sudo)
    else
      inhibit_runner=(pkexec)
```

Two things combine:

1. `omarchy update` gives itself a tty (via `script`), so `[[ -t 0 ]]` is **true** and the `sudo -v` branch is
   taken even in a fully unattended run.
2. `sudo -v` is governed by sudo's `verifypw` option, whose default is **`all`**. Under `verifypw=all`, `sudo -v`
   demands a password if *any* rule for that user requires one. A stock Arch install has wheel's
   `%wheel ALL=(ALL:ALL) ALL` alongside the `NOPASSWD: ALL` file that `omarchy-sudo-passwordless` writes — so
   the passworded wheel rule is enough to make `sudo -v` prompt, and the `NOPASSWD` file never gets a say.

So `omarchy sudo passwordless` does not actually make `omarchy update` passwordless.

### Reproduce

1. `omarchy sudo passwordless`
2. Run `omarchy update` non-interactively (no human to type a password)
3. Observe the hang at `[sudo] password for <user>:`, then the `set -e` abort — with the snapshot already created

Observed on Omarchy 4.0.1: a 5-minute hang, then abort.

### Workaround that works

Add `verifypw=any` for the user in a sudoers drop-in:

```
Defaults:<user> verifypw=any
```

With that in place the same `omarchy update` completed in about 20 seconds.

### Suggested fix

Either drop the `sudo -v` pre-flight (it is only warming the sudo timestamp — `sudo` will prompt when actually
needed), or make it non-fatal and non-blocking (`sudo -n -v || true`) so a passwordless configuration is
respected and an unattended run degrades to `pkexec`/failure fast instead of hanging. Alternatively, have
`omarchy-sudo-passwordless` also set `verifypw=any` for the user, so the guarantee it advertises holds for
`sudo -v` too.

### Environment

Omarchy 4.0.1-1, Arch, x86_64, KVM guest. sudo defaults unmodified apart from the `NOPASSWD` file written by
`omarchy sudo passwordless`. First observed 2026-08-28.