### What happened

Running `sudo omarchy plymouth set ...` completes "successfully" (rebuilding the
UKI and switching the default Plymouth theme) while silently skipping every
theming step. It leaves a half-applied boot screen: the new logo is installed,
but the background colour and the recoloured widgets are not.

`omarchy-plymouth-set` resolves its source assets through `$OMARCHY_PATH`:

```bash
find "$OMARCHY_PATH/default/plymouth" -maxdepth 1 -type f -exec cp -t "$staging_dir/" {} +
...
sddm_template="$OMARCHY_PATH/default/sddm/omarchy/Main.qml"
```

`OMARCHY_PATH` is exported only by `~/.bashrc` (via
`/usr/share/omarchy/default/bash/env-bootstrap`), which `sudo` does not source.
Under `sudo` the variable is empty, so the paths collapse to `/default/plymouth`
and `/default/sddm/omarchy/Main.qml`, the staging dir stays empty, and every
subsequent step operates on files that were never staged:

```
find: '/default/plymouth': No such file or directory
sed: can't read /tmp/tmp.rBibq3DGtW/omarchy.script: No such file or directory
magick: unable to open image '/tmp/tmp.rBibq3DGtW/bullet.png': No such file or directory
magick: unable to open image '/tmp/tmp.rBibq3DGtW/entry.png': No such file or directory
magick: unable to open image '/tmp/tmp.rBibq3DGtW/lock.png': No such file or directory
magick: unable to open image '/tmp/tmp.rBibq3DGtW/progress_bar.png': No such file or directory
Building UKI for linux (7.1.9-arch1-2)
...
==> Unified kernel image generation successful
Copied: /tmp/limine-mkinitcpio.FO2DJ3/linux.efi -> /boot/EFI/Linux/omarchy_linux.efi
sed: can't read /default/sddm/omarchy/Main.qml: No such file or directory
cp: cannot stat '/tmp/tmp.rBibq3DGtW/bullet.png': No such file or directory
cp: cannot stat '/tmp/tmp.rBibq3DGtW/entry.png': No such file or directory
cp: cannot stat '/tmp/tmp.rBibq3DGtW/lock.png': No such file or directory
```

### Why this is not a duplicate of #8369 / #8769 / #9065

Those cover the same root cause but a different failure mode. `omarchy-update-dev`
sets `set -euo pipefail` (line 5) and therefore aborts loudly with "unbound
variable".

`omarchy-plymouth-set` has **no `set` line at all**. It does not abort. It runs
to completion past six failed commands and still executes the two
state-changing steps:

```bash
sudo plymouth-set-default-theme omarchy
sudo limine-mkinitcpio   # or mkinitcpio -P
```

So the user gets a full initramfs/UKI rebuild, a "success" exit, and a boot
screen that is half-themed — with no indication anything went wrong unless they
read the scrollback. That is the bug worth fixing independently of the shared
root cause.

### The `requires-sudo=true` metadata invites the broken invocation

`omarchy-plymouth-set` declares:

```
# omarchy:requires-sudo=true
```

This is metadata only — the dispatcher never elevates; it just re-emits the flag
in `omarchy commands --json`. The script self-elevates through internal `sudo`
calls, and its own example has no `sudo` prefix:

```
# omarchy:examples=omarchy plymouth set '#1d2021' '#ebdbb2' ~/.local/state/omarchy/current/theme/plymouth/logo.png
```

But a user reading `requires_sudo: true` in `omarchy commands --json`, or in the
help output, will reasonably type `sudo omarchy plymouth set ...` — which is
exactly the invocation that breaks. Correct usage and the documented
requirement point in opposite directions.

### Scope

14 commands declare `requires-sudo=true` and dereference `$OMARCHY_PATH` with no
fallback, so each is exposed to the same failure if invoked under `sudo`:

```
omarchy-channel-set                 omarchy-refresh-pacman
omarchy-hibernation-setup           omarchy-refresh-plymouth
omarchy-install-gaming-battlenet    omarchy-refresh-sddm
omarchy-install-terminal            omarchy-reinstall-pkgs
omarchy-plymouth-set                omarchy-setup-security-fingerprint
omarchy-refresh-limine              omarchy-snapshot
                                    omarchy-toggle-hybrid-gpu
                                    omarchy-voxtype-install
```

Five other commands already guard it (`omarchy-apply-system`,
`omarchy-apply-hardware`, `omarchy-provision-owner`, `omarchy-provision-user`,
`omarchy-migrate`), and `/etc/skel/.config/hypr/hyprland.lua` uses the same
defensive pattern:

```lua
dofile((os.getenv("OMARCHY_PATH") or "/usr/share/omarchy") .. "/default/hypr/bootstrap.lua")
```

The fallback idiom is established in the tree; these 14 just don't use it.

### Steps to reproduce

1. `sudo omarchy plymouth set 101040 C3C3CF /path/to/any-logo.png`
2. Observe the `find`/`sed`/`magick` errors above.
3. The initramfs rebuilds and the command exits without a non-zero status.
4. `/usr/share/plymouth/themes/omarchy/logo.png` is updated, but
   `omarchy.script` still has the previous `Window.SetBackgroundTopColor`, and
   `bullet.png`/`entry.png`/`lock.png`/`progress_bar.png` are unrecoloured.

### Expected

Either the command works under `sudo`, or it fails fast before touching the
initramfs.

### Suggested fix

Three small, independent changes:

1. Default the variable in the affected scripts:
   `: "${OMARCHY_PATH:=/usr/share/omarchy}"`
2. Add `set -euo pipefail` to `omarchy-plymouth-set` so a staging failure can
   never reach `plymouth-set-default-theme` or the initramfs rebuild.
3. Either make `requires-sudo=true` mean the dispatcher elevates, or rename it
   so it stops reading as "prefix this with sudo".

### System

- Omarchy 4.0.1-1
- Kernel 7.1.9-arch1-2
- Intel Core i5-5350U / Intel HD Graphics 6000 (Broadwell-U GT3)
- Boot: UKI via `limine-mkinitcpio`, encrypted btrfs root