Prepare 4.0.3rc4 trust bootstrap

[malik-na]

Problem

Omarchy Mac 4.0.3 needs one explicit trust-bootstrap release before its package repository can require a fork-owned signing key. Existing 4.0.2 clients do not have that key, so signing the first keyring package with only the new key would make the upgrade unable to bootstrap itself.

This PR now prepares 4.0.3rc4 as the final unsigned bootstrap candidate. It retains the existing Optional TrustAll policy for this one disclosed transaction, installs the exact pinned fork public key, and leaves signature enforcement to the following signed RC. It does not publish or merge anything.

Signing bootstrap changes

• Adds omarchy-mac-keyring with primary fingerprint F3C5AE3FCFFC738C301E30A8F0C548C0D27279F7 and signing subkey 6C2597C6E69FC4898D3D560E331307696030285E.
• Pins the public key bytes in source; no keyserver lookup is used for the fork key.
• Makes omarchy-mac-keyring a hard dependency of omarchy while retaining upstream omarchy-keyring.
• Adds a new existing-user migration that installs the keyring if a partial/manual upgrade omitted it, runs pacman-key --populate omarchy-mac, and verifies the complete primary fingerprint.
• Adds the same keyring to fresh builds and fresh channel preflight. The private preflight keyring creates only a disposable local-signing key; host secret keys are never copied.
• Adds guarded policy rendering for the follow-up signed RC. It rejects custom/ambiguous repository layouts and symlinked pacman configuration, installs atomically, and verifies effective policy with pacman-conf.
• Bumps source from 4.0.3rc3 to 4.0.3rc4 because trust delivery changes the package payload.

Existing 4.0.3 fixes retained

The branch also contains the previously qualified 4.0.3 work: fresh/existing zram parity, Hermes defaults, ARM channel transaction isolation, package-source compatibility, GRUB/Btrfs recovery and factory reset, owner re-key retry safety, mkinitcpio .pacnew preservation, and migration coverage.

Validation

• Focused bootstrap QA: 10 suites and 100 assertion groups pass. The only initial update-lock failure was its real 10 GiB free-space guard; the documented low-space override rerun passed all seven groups.
• Final rc4 transition review: six affected suites, 36 assertions, pass with no source drift. Fresh templates, rendered lanes, and the migration all retain the bootstrap policy; the migration only establishes trust.
• Real keyring package build passed checksum validation. Its three installed keyring files match the committed source bytes exactly, and its install hook calls pacman-key --populate omarchy-mac.
• Isolated pacman-key --init, exact public-key import, local signing, and repeat population pass. GnuPG reports the expected primary and signing-subkey fingerprints.
• Earlier rc3 native package qualification passed fresh and 4.0.2 upgrade transactions with dependencies, hooks and scriptlets, two new-user skeletons, customized mkinitcpio preservation, and 1,462 source comparisons per root.
• Earlier hosted CI was green at 1052c83d; this rc4 commit requires a new hosted run.

Independent evidence: rc-evidence/reviewer/bootstrap-signing-qa/rc4-trust-only/REPORT.md in the qualification workspace.

Required release order

1. Review and merge this source change when ready.
2. Build and publish rc4 as the clearly labeled final unsigned bootstrap candidate.
3. Upgrade the canary to rc4 and verify the fork key is installed and trusted.
4. Publish the fully signed 52-package repository and signed database.
5. Build the next source RC with PackageRequired DatabaseRequired TrustedOnly, then test the signed fresh-install and bootstrap-to-signed upgrade paths.

Limits

• No package or release was published by this PR.
• The preserved physical M1 was not rebooted or factory-reset during this signing change.
• rc4 is intentionally not the promotable signed candidate. The next signed RC needs separate native fresh/upgrade, reboot, desktop and rollback qualification.

[malik-na]

Final bootstrap validation

Hosted ARM initially exposed a real ordering bug: build-packages.sh checked the upstream recipe tree for omarchy-mac-keyring before prepare_omarchy_recipes injected that fork-local recipe. Commit e639d8e3 moves completeness validation to the prepared tree. Commit 46f3294d makes the regression test honor CI's OMARCHY_PKGS_PATH in either repository-root or pkgbuilds form.

Independent differential review reproduced the parent failure with the exact pinned recipe checkout, then confirmed the fixed builder injects and validates the keyring before dependency installation or output mutation. Local contract tests pass for both path forms.

All replacement hosted checks are green at 46f3294d, including both complete test/all runs and the 12m30s ARM package-source, fresh-install, and repeat-install job. This changes no release sequencing: rc4 remains the final unsigned trust bootstrap, and strict rc5 remains stacked behind the signed repository baseline.

[wesleygrimes]

I checked the new commits:

• Residual auto-unlock issue: fully fixed in 1052c83. It detects every key/drop-in—including dangling symlinks—retries cleanup, and adds focused tests.
• Package-signing concern: addressed as an explicit transition, not eliminated for rc4. rc4 remains one final unsigned Optional TrustAll transaction that installs a pinned fork key; rc5 will enforce signatures. That bootstrap still carries the original supply-chain risk, but the limitation and required release sequence are now clear.
• All seven replacement CI checks pass.

No new egregious issue jumped out in the fixes. The auto-unlock blocker is resolved; accepting the one-time unsigned bootstrap is now the remaining policy decision.