Add a native Arch/CachyOS package via its own AUR publish workflow

Part of triple-c#34's third ask ("I would like to also have an
Arch/CachyOS native version as well"), addressed separately from the
Wayland crash fix (fix/wayland-webkit-egl-crash) since it's an unrelated
feature, not a bug.

packaging/arch/PKGBUILD is a "-bin" AUR package repackaging the same .deb
build-app.yml already produces — no Rust/Node toolchain needed to install
it, and the user gets exactly the binary the project ships and tests.
Verified end to end against a real release (v0.4.14) rather than going by
Tauri's generic docs: downloaded the actual .deb, ldd'd the actual binary
to ground-truth `depends` (dropped `pango` and `libayatana-appindicator`
from an earlier draft — the first is already pulled in transitively by
gtk3, the second was never linked at all since this app has no tray icon
or menu), and ran a real makepkg/namcap/pacman -U cycle. namcap caught a
real issue this way (missing license file under
/usr/share/licenses/triple-c-bin/), now fixed by fetching LICENSE
alongside the .deb.

.gitea/workflows/publish-aur-package.yml does the actual publishing:
given a version (or "latest"), it finds that release's real Linux asset
on GitHub, downloads it, computes real checksums, renders the PKGBUILD
template, validates the result with makepkg and namcap inside a real
Arch container, and pushes to AUR. workflow_dispatch only, deliberately —
the same reasoning that killed sync-release.yml in triple-c#32 (releases
are assembled by build-app.yml across three separate platform jobs, so
there's no single automatic event that fires only once the Linux .deb
this needs actually exists) applies here too.

Requires a repo secret this workflow cannot set up itself:
AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or
been given co-maintainer access to) triple-c-bin — both one-time manual
steps on aur.archlinux.org. Until that secret exists, the workflow fails
loudly at the push step rather than silently doing nothing. See
packaging/arch/README.md for the full maintenance flow.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ

packaging/arch/README.md

@@ -0,0 +1,46 @@
+# Arch / CachyOS package
+
+`PKGBUILD` here is the AUR `triple-c-bin` package's template — see triple-c#34
+(the "I would like to also have an Arch/CachyOS native version" part of it).
+
+## Why "-bin"
+
+It repackages the same `.deb` `build-app.yml` already produces, rather than
+building from source. That means `makepkg` never needs a Rust toolchain,
+Node, or the dozen `-dev` packages CLAUDE.md lists for building Triple-C
+itself — and a user gets exactly the binary the project ships and tests,
+built on Ubuntu 24.04 in CI. Verified end to end against a real release
+(v0.4.14): downloaded the actual `.deb`, confirmed every `depends` entry
+against a real `ldd` of the actual binary (two packages that looked right
+from Tauri's own docs — `pango`, `libayatana-appindicator` — turned out not
+to be real dependencies of *this* binary and were dropped), and ran a real
+`makepkg`/`namcap`/`pacman -U` cycle rather than guessing at the shape.
+
+## Publishing
+
+`.gitea/workflows/publish-aur-package.yml` does the actual work: given a
+version (or "latest" if none is given), it finds that release's real Linux
+asset on GitHub, downloads it, computes real checksums, renders this
+template into a version-specific PKGBUILD, validates it with `makepkg` and
+`namcap` inside a real Arch container, and pushes the result to AUR.
+
+It is `workflow_dispatch`-only, deliberately — see the workflow file's own
+header comment for why an automatic trigger isn't safe here (the same reason
+`sync-release.yml` didn't work and was removed in triple-c#32).
+
+**Before it can push anything**, an AUR account has to exist and the
+`triple-c-bin` package has to have been created (or you added as a
+co-maintainer) under it — both are one-time, manual steps on
+https://aur.archlinux.org, since there's no API to automate creating an
+account or a new package. Once that's done, add the account's SSH private
+key as the `AUR_SSH_PRIVATE_KEY` secret on this repo. Until that secret
+exists, the workflow fails at the "Push to AUR" step with a message saying
+so, rather than silently doing nothing.
+
+## What's hand-maintained vs. generated
+
+`pkgver`/`pkgrel`/`source`/`sha256sums` in this file are placeholders —
+the workflow rewrites them for every real publish and never commits the
+result back here, so don't read this file's `pkgver` as "the last published
+version." Everything else (`depends`, `pkgdesc`, `package()`) is meant to be
+edited by hand normally, the same as any other PKGBUILD.