What

Implements Option 2 of #6334: automated AUR publishing on release.

PR #6314 added the AUR package sources under packaging/aur/ but nothing pushes them to the Arch User Repository.
This adds the automation so yay -S librefang-bin / librefang-desktop-bin / librefang-docker track each LibreFang release, pinned to the exact version (never latest).

How

Three new release.yml jobs — sync_aur_bin, sync_aur_desktop, sync_aur_docker — modeled directly on the existing sync_homebrew / sync_homebrew_cask jobs.
They share the same tag/dispatch if: guard and each waits (needs:) on the build job that produced its asset (cli_linux / desktop / docker-manifest).
Split into three independent jobs (not a matrix) so a desktop build failure cannot block the librefang-bin publish, and vice versa.

A shared composite action (.github/actions/publish-aur) runs packaging/aur/publish-to-aur.sh inside archlinux:base-devel (via docker run on the ubuntu host, so actions/checkout keeps using the host's Node/git).
The script self-bootstraps: as root it installs the Arch tooling and drops to an unprivileged builder (makepkg refuses to run as root), then per package it:

• bumps pkgver (encoding the tag's first - as _, e.g. v2026.6.26-beta.24 → 2026.6.26_beta.24) and resets pkgrel to 1;
• for librefang-desktop-bin, reads the Tauri bundle version off the actual LibreFang_<ver>_amd64.deb asset name (it differs from the tag, exactly like the cask sync);
• for librefang-docker, re-pins the ghcr.io/librefang/librefang:<version> tag inside the helper script and env file;
• regenerates sha256sums (updpkgsums) and .SRCINFO (makepkg --printsrcinfo);
• clones ssh://[email protected]/<package>.git, copies only the committed source files (never downloaded artifacts), and pushes if anything changed.

The committed packaging/aur/ files remain a working baseline for local makepkg; the release-correct pkgver / sha256sums / .SRCINFO are generated into the AUR repositories on each tag.

Maintainer setup required (the issue's Option-2 prerequisites)

The jobs degrade to a no-op with a notice until AUR_SSH_PRIVATE_KEY is configured, so this PR is safe to merge first.
To activate:

1. Create the three AUR repositories under the owning AUR account.
2. Add AUR_SSH_PRIVATE_KEY (and optionally AUR_KNOWN_HOSTS, AUR_GIT_NAME, AUR_GIT_EMAIL) as repo secrets — full commands in .github/SECRETS.md.
3. Validate via workflow_dispatch on release.yml (channel=current, tag=<existing release>).

Notes

• Publishes for every v* tag including betas, matching the Homebrew sync and the project's current beta-only cadence; the version is always pinned (no floating latest), per the issue's requirement.
• known_hosts is fetched with ssh-keyscan at runtime (TOFU) unless AUR_KNOWN_HOSTS is set; the SSH key file is wiped on step exit via a trap.
• archlinux-keyring is refreshed in the same pacman transaction to avoid the stale-keyring signature-verification flake.

Verification

• python3 -c "yaml.safe_load(...)" parses release.yml and action.yml.
• bash -n passes on publish-to-aur.sh and the composite action's run block; the run block contains no ${{ }} interpolation (no shell-injection surface).
• All three needs: targets (cli_linux, desktop, docker-manifest) exist; the three new job IDs are unique across the file.
• Simulated the version round-trip (beta/stable/rc/lts), the pkgver/pkgrel edits, the desktop .deb version parse, and the Docker image-tag sed against the real PKGBUILDs — the image-tag regex replaces only the version and preserves the surrounding ${...:-...} brace.

Live AUR push is exercised the first time the maintainer dispatches a release with the secret configured (it cannot run in CI without the key).

Refs #6334