Publish an aarch64 tree at pkgs.omarchy.org

[oceanapplications]

pkgs.omarchy.org serves only x86_64 today:

	stable/$arch/omarchy.db	edge/$arch/omarchy.db
x86_64	200	200
aarch64	404	404

[omarchy] is defined as Server = https://pkgs.omarchy.org/stable/$arch, and pacman
substitutes $arch from Architecture in pacman.conf. So on ARM64 that repository simply
does not resolve, and an installed Omarchy cannot install or update any Omarchy package from
the official source.

The tooling already supports it

This is a publishing step rather than a code change — bin/build already takes the flag:

--arch <arch>        Target architecture (x86_64 or aarch64, default: x86_64)

along with update_arch_paths and QEMU setup for building aarch64 on an x86_64 host, and
bin/sync-repo takes the same --arch. The README documents the QEMU prerequisite under
aarch64 Builds. As far as I can tell the only missing piece is running that path for
aarch64 and syncing the result.

Why it matters now

aarch64 Omarchy works. It runs on Arch Linux ARM under Parallels on Apple Silicon —
GPU-accelerated via virgl, Hyprland under uwsm, Limine with UKI and snapper rollback — and an
aarch64 ISO builds, installs to an encrypted target, and boots unattended into the desktop.

Everything needed to build the packages for aarch64 is either already here or proposed:

• Add aarch64 to arch=() for packages that build natively on ARM64 #195 — nine packages that build natively on ARM64 gain aarch64 in arch=()
• 1password: build for aarch64 #197 — 1password, which upstream publishes an aarch64 build of

What is missing is somewhere to put them. Without a published tree, anyone wanting to run
Omarchy on ARM64 has to build roughly 34 packages locally and serve them from a file://
repository, which is what I have been doing. That makes the work unreproducible for anyone
else, and it is the only remaining blocker of its kind — every other gap I hit has a patch
proposed against it:

omacom/omarchy-iso#121	aarch64 ISO build
omacom/omarchy#8039	three x86-only assumptions in the install path
Zesko/limine-entry-tool!63	Limine's unnecessary x86_64 gates (merged)
Zesko/limine-entry-tool!64	Limine finding kernels that ship no pkgbase marker (merged, awaiting a release)

What I am asking for

A published pkgs.omarchy.org/{stable,edge}/aarch64/ tree, even if it starts as a subset.

Happy to help — I have an aarch64 build environment set up and can test against the tree once
it exists, or supply the list of packages that currently build cleanly there.

Note on scope

Not every package can build for aarch64, and I am not suggesting otherwise. Roughly 38 in the
current lists have no ARM64 build — mostly x86 platform hardware (intel-ucode, nvidia-*,
linux-t2, syslinux, refind) and x86-only guest tooling (open-vm-tools, hyperv,
virtualbox-guest-utils-nox). Those are meaningless on ARM rather than gaps. A handful are
genuine gaps: obs-studio, pinta, dotnet-runtime. cursor-bin is blocked separately,
since Arch Linux ARM carries no electron* package at all.