Move install-time plumbing out of the setup namespace

setup is where a user goes to configure something: direct boot, security
keys, hibernation. These three are not that. omarchy-apply-system is the
ISO's entry point in the target chroot, omarchy-apply-hardware is what it
calls for device quirks, and omarchy-apply-lock is called by
install/config/lockscreen-pam.sh.

apply is the verb they already used to describe themselves, and it carries
the contract: declared state under install/ converged onto the machine,
idempotent, safe to repeat.

The group gets no GROUP_DESCRIPTIONS entry on purpose. That table drives the
top-level group list on its own, so an entry would put apply back in front of
users even with every command in it hidden, the way provision already stays
out. A test covers it.

The ISO installs the runtime from the mirror it ships with, so it moves to
the new names in lockstep and no compatibility route is needed.

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

bin/omarchy-upgrade-to-quattro

@@ -612,16 +612,16 @@ configure_snapper_policy() {
 }
 
 configure_lock_authentication() {
-  local setup_lock=/usr/share/omarchy/bin/omarchy-setup-lock
+  local apply_lock=/usr/share/omarchy/bin/omarchy-apply-lock
 
-  [[ -x $setup_lock ]] || fail "$setup_lock is unavailable; lock screen authentication could not be configured."
+  [[ -x $apply_lock ]] || fail "$apply_lock is unavailable; lock screen authentication could not be configured."
 
   log "Configuring lock screen authentication"
   as_root env \
     OMARCHY_INSTALL_USER="$target_user" \
     OMARCHY_PATH=/usr/share/omarchy \
     PATH="$package_path" \
-    "$setup_lock"
+    "$apply_lock"
 }
 
 create_pre_upgrade_snapshot() {