[fix] Refresh the factory lock for available ARM packages

[Fail-Safe]

Factory builds stop before package installation when the rolling ARM repository transaction differs from the checked-in lock. Refresh the lock against current upstream v0.4.0 (7c7acee) and current repository metadata.

Changes

Only seven package versions differ from current main:

• libadwaita: 1:1.9.3-1 to 1:1.9.4-1
• libde265: 1.1.2-1 to 1.1.3-1
• libtirpc: 1.3.7-1 to 1.3.8-1
• linux-aarch64 and linux-aarch64-headers: 7.2.5-1 to 7.2.6-1
• qt6-declarative: 6.11.2-1 to 6.11.2-2
• tzdata: 2026c-1 to 2026d-1

The reviewed Hyprland, Aquamarine, Hyprtoolkit, and Mesa versions remain unchanged. The package list, build specification, and ABI pins are unchanged from current main. This changes the factory-image transaction only; it does not update existing VM disks.

Validation of this revision

• Generated the lock with the project refresh command using fresh isolated repository databases and source rebuilds of the reviewed ABI packages.

• Full make test passed: 107 guest tests, 268 native tests, launcher/network/storage checks, and 14 disk-resize tests. The optional virtio-pinch guest ABI test was skipped because no test runtime binary was supplied.

• Built the complete factory guest from a brand-new empty package/source work volume. Package integrity checks, source-built ABI packages, the expected patched Hyprland binary hash, final filesystem checks, image compression, and manifest generation passed.

• This refresh did not rebuild the QEMU runtime, package a new Mac app, or boot the resulting factory image. A fresh-image first-boot check remains release qualification.

Rolling repositories can change again; this refresh restores the transaction available during validation rather than providing a permanent package archive.

[jtavin-smp]

Heads up that a fresh refresh no longer resolves, as of today. This lock was generated on 2026-09-15 and CI only checks the lock against packages.txt and the spec, never re-running a live resolve, so a green check here does not mean the refresh command still works.

Running guest/build-container.sh --refresh-package-lock now fails at the resolve step:

:: unable to satisfy dependency 'libaquamarine.so=14-64' required by hyprland
error: failed to prepare transaction (could not satisfy dependencies)

Arch Linux ARM aarch64/extra today:

Package	Version	aquamarine soname
aquamarine	0.15.0-2	provides .so=14
hyprland	0.56.2-3	requires .so=14
hyprtoolkit	0.5.4-6	requires .so=14

Upstream is now self-consistent on .so=14. The factory is not: spec.json pins abiPackagePins at aquamarine 0.14.0-2 (.so=13) with hyprtoolkit 0.5.4-6.1 rebuilt against it, and supplyChain.omarchy.packages.hyprland expects 0.56.1-3, which ALARM no longer carries. hyprland is not an ABI pin and is not held during a factory build, so it resolves to 0.56.2-3 and demands the .so=14 the pinned aquamarine cannot provide.

The 0.14 pin was the right call when ALARM's Hyprland needed .so=13 (#136, #142). Now that Hyprland has moved, the pin is what blocks resolution rather than what protects it.

I verified this is not specific to any one branch: the same refresh fails identically with an unmodified main package list, so it is not caused by a package being added. Practically it blocks any PR that has to relock — #218 is stuck on it.

I have not proposed a fix here because dropping the ABI pins also means re-checking that patches/hyprland/rounded-border-coverage.patch still applies to 0.56.2 and that the reviewed Hyprtoolkit rebuild is still wanted, which seems like a maintainer call rather than something to slip into an unrelated PR.