Migrate Macs from a verified download of omarchy-mac-boot, handing files over inside the transaction

[maralcbr]

Ticket 53, owner decision 1: automatic delivery through omarchy update to Macs that have no official omarchy-mac-boot. Stacked on #601 (the deferred result).

Engine (omarchy-mac-boot)

• omarchy-mac-migrate --payload DIR runs the engine, adapters, helper commands and packaged target from an unpacked omarchy-mac-boot that is root's and writable by no one else (ancestors included). Preflight defers unless the transaction installs that same version.
• Handover fix (the old migrate-engine.sh:1066-1075 path): a planned removal that shares files with what stays installed stops the migration at prefetch, before anything changes, and again before the post-transaction pacman -R, since -R deletes every file of the package it removes. On mx-mac, omarchy-dev leaves inside the one transaction through omarchy's conflict, so its five commands pass to omarchy-mac-boot with no --overwrite.
• Exit contract: 0 migrated/awaiting reboot/nothing to do, 75 stopped before anything changed (preflight refusals, and any failure before the journal exists), 1 failed part way (resumes).
• omacom's own omarchy-dev (no fork updaters or records, no retired repo/key, no unsigned repo, [omarchy] on pkgs.omarchy.org): "nothing to migrate", exit 0. Beside retired trust it is a deferred refusal.
• Reviewed migrations table, applied per Omarchy user in the defaults step: recorded as done instead of run, as on a fresh image: 1784476564, 1784917531, 1785273276, 1785944594, 1786137597, 1786482992, 1786605598, 1789325478, 1789444024 (x86 Limine/T2/NVIDIA/linux-omarchy initramfs and boot-chain repairs), 1786391100 (Intel Mac Broadcom quirk), 1785424256 (systemd-oomd stays off on Macs), 1790347292 (plus its machine marker). From mx-mac, the 13 official migrations the fork's runner settled as handled (its .sh.skipped record says so) are recorded as done; the ones it skipped run on the new packages. Everything else pending runs on the next update, as for any upgraded install.
• The download is removed once the migration is complete.

Runtime: omarchy-mac-migrate-bootstrap fetches omarchy-mac-boot from the Mac's channel on pkgs.omarchy.org, accepts it only with a signature by the pinned Omarchy key 40DFB630… (from omarchy-keyring, pacman's keyring or keys.openpgp.org), checks the repository's checksum, unpacks it into /var/lib/omarchy-mac/bootstrap/payload (root only) and runs its engine. Nothing runs until the published package ships a migration target; every stop before a change exits 75. A channel other than the packaged one is kept in /etc/omarchy-mac/migration-target (converted mx-mac Macs keep rc/edge). A migration in progress resumes with the download it started from, and with the installed package once the transaction ran. --prime only fetches and unpacks (used by the final mx-mac release). The same script is vendored byte-identical into that release.

Tests

• packages/omarchy-mac/boot/test/mac-migrate-mx-test.sh: an mx-mac Mac without omarchy-mac-boot migrating from the download (engine and adapter from the payload, the five commands change owner, omarchy-dev removed in the transaction, nothing overwritten, installed package finishes after reboot, download removed); no conflict ⇒ stops at prefetch with nothing changed; stale payload version ⇒ 75, nothing changed; group-writable payload refused; omacom dev channel ⇒ nothing to migrate, with a fork key ⇒ 75; settled-migrations table. Fixture pacman now records files on --dbonly as pacman does. Refusal expectations move from 2 to 75.
• test/shell.d/mac-migrate-bootstrap-test.sh: file:// repositories and a throwaway key: other platform, no repo/package/target ⇒ 75, wrong signer or checksum ⇒ never unpacked, packaged target, keyring from omarchy.gpg, engine status passed through, kept channel, prime/reuse/refresh, resume before and after the transaction, admin candidate-set target left alone.
• Real pacman 7.1 in an Arch container (disposable, omarchy-gpu), with the engine's shared_files: one -S of omarchy + omarchy-mac-boot over omarchy-dev removes it in that transaction and hands the five commands over with no --overwrite; --dbonly records the new file lists; without the conflict the rehearsal keeps omarchy-dev, the guard names the five commands and the real transaction refuses them; with --overwrite, pacman -R omarchy-dev deletes them (why the guard exists). 10/10.
• Boot suite test/all and runtime test/all in an Arch container: only the files in .github/known-test-failures fail. CI does not run on stacked PRs; it will once this is retargeted.

Second review: no trust hole found in the payload or the bootstrap; fixed what it verified: failures before the journal now defer instead of failing the update, curl gets --max-time and --proto-redir, the download is dropped when a payload-run migration finishes, resume prefers the installed package after the transaction, 1784476564 joins the table. Left as risks: omarchy.db itself is unsigned (only the package signature is pinned), and a post-transaction shared-file refusal needs a hand pacman -R.

Release order: merge #601, this, then #603; re-pin omarchy-mac-boot in omarchy-pkgs from a commit with this PR before (or with) #603's target.