Make package ownership the Quattro update boundary

[ryanrhughes]

Why

#8655 exposed a dangerous rollback boundary in the automatic Pacman file-conflict recovery. #9053 made that recovery safer, but kept the wrong long-term model: an ordinary update still tried to move unexpected root paths out of Pacman's way.

This supersedes both approaches. The 3.x to Quattro upgrade is the ownership boundary. It adopts the known legacy files once; after that, ordinary updates trust Pacman's package database and fail on unexpected filesystem state instead of rewriting it.

What changed

• omarchy-upgrade-to-quattro uses exactly one --overwrite='*', scoped to the omarchy-settings install that adopts the known 3.x configuration paths. No other Quattro install uses overwrite.
• omarchy-update-system-pkgs performs a normal pacman -Syu with no overwrite, quarantine, root-path moves, or filesystem-conflict retry.
• The upgrader now routes release candidates to the rc repository and production package pair; dev packages are confined to edge, so the v4.0.2 RC can be tested through the real 3.x upgrade path.
• A genuine package transaction conflict can still be handed to interactive Pacman on an attended terminal; unattended updates fail closed with the original error.
• The vulnerable conflict-recovery helper is removed.
• Chromium's EULA sentinel and the static GPU/keyboard sleep hooks become package-backed state.
• Exact-hash migrations remove only known legacy unowned files. Modified, symlinked, foreign-owned, or package-owned state is preserved; inspection and privilege failures retry rather than guessing.
• Tests build the companion settings package and prove its manifest covers every known 3.x collision path, including its backup=() entries.

Proof

From this checkout, with the companion package repository checked out on its linked branch:

export OMARCHY_PATH=$PWD
export OMARCHY_PKGS_PATH=/path/to/omarchy-pkgs

OMARCHY_PKGS_PATH="$OMARCHY_PKGS_PATH" bash test/shell.d/quattro-ownership-bridge-test.sh
bash test/shell.d/upgrade-to-quattro-channel-test.sh
bash test/shell.d/update-file-conflict-test.sh
bash test/shell.d/update-package-conflict-test.sh
bash test/shell.d/upgrade-to-quattro-test.sh
bash test/shell.d/chromium-eula-transition-test.sh
bash test/shell.d/legacy-system-state-transition-test.sh
bash test/shell.d/system-sleep-hook-transition-test.sh

To reproduce the package-level proof against the actual built payload:

artifact_dir=$(mktemp -d)
for package in omarchy-dev omarchy-settings-dev; do
  (
    cd "$OMARCHY_PKGS_PATH/pkgbuilds/$package"
    env OMARCHY_SRC="$OMARCHY_PATH" PKGDEST="$artifact_dir" makepkg --nodeps --force --cleanbuild --clean
  )
done

The focused suite passes. The aggregate CLI suite passes, and 216/219 shell test files pass. The remaining three failures reproduce unchanged on the base branch: an IPC-handler timing flake, an installed-helper ambient-environment test, and a /home mount-namespace assumption.

Release order

1. Merge this Quattro guard.
2. Merge and build the companion package PR.
3. Stage and test both changes in the v4.0.2 patch train.
4. Ship v4.0.2 so omarchy and omarchy-settings are pinned together.
5. Only then merge the 3.x master, rc, and dev bootstrap PRs.

The legacy bootstrap PRs must not merge before v4.0.2 is published, or 3.x users could adopt the older 4.0.1 payload.

From the package repository, the release commands are:

bin/omarchy-release pick 9070
bin/omarchy-release rc
# After validating the release candidate:
bin/omarchy-release ship

For a machine already on the vulnerable Quattro 4.0.1 updater, the safe first hop after v4.0.2 is published is:

sudo env OMARCHY_ALLOW_DIRECT_PACMAN=1 pacman -Syu
omarchy update

Companion PRs

• Package ownership payload: Package Omarchy static system state omarchy-pkgs#239
• 3.x bootstrap PRs (do not merge until v4.0.2 is published): master Confine Quattro overwrite to ownership bootstrap #9072, rc Backport constrained Quattro ownership bootstrap to rc #9073, dev Backport constrained Quattro ownership bootstrap to dev #9071