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/PKGBUILD

@@ -0,0 +1,75 @@
+# Maintainer: Triple-C Contributors
+#
+# This file is regenerated by .gitea/workflows/publish-aur-package.yml on every
+# publish — pkgver, the source URL and sha256sums are rewritten from the real,
+# already-uploaded release asset, never guessed. Editing pkgver/source/
+# sha256sums by hand here only matters until the next automated run overwrites
+# them; everything else (depends, pkgdesc, package()) is meant to be hand-
+# maintained normally.
+#
+# "-bin" rather than building from source: this repackages the same .deb
+# build-app.yml already produces and publishes, so a user gets exactly the
+# binary the project ships and tests, and `makepkg` never needs a Rust
+# toolchain, Node, or the dozen -dev packages CLAUDE.md lists for building
+# Triple-C itself. The trade-off is the one every "-bin" package makes: it
+# assumes the glibc the CI runner (Ubuntu 24.04) linked against is compatible
+# with the installing system's — true for essentially every currently
+# supported Arch install, since Arch tracks glibc newer than Ubuntu 24.04
+# ships, and forward compatibility is the direction that holds.
+pkgname=triple-c-bin
+pkgver=0.4.0
+pkgrel=1
+pkgdesc="Sandbox Claude Code inside Docker containers"
+arch=('x86_64')
+url="https://github.com/shadowdao/triple-c"
+license=('MIT')
+# Verified against a real release asset (v0.4.14), not Tauri's generic docs:
+# downloaded Triple-C_0.4.14_amd64.deb, installed each of these into a real
+# Arch container, and re-ran `ldd` on the actual binary until nothing came
+# back "not found". `pango` and `libayatana-appindicator` were both in an
+# earlier draft — pango isn't directly linked (gtk3 already pulls it in
+# transitively, and namcap correctly flags declaring it as redundant), and
+# libayatana-appindicator is in Tauri's own linux dependency list but this
+# binary never links it at all: there is no tray icon or menu in this app
+# (see CLAUDE.md's note that `core:menu`/`core:tray` are dropped for the
+# same reason), so it was never a real dependency to begin with.
+depends=('cairo' 'desktop-file-utils' 'gdk-pixbuf2' 'glib2' 'gtk3'
+         'hicolor-icon-theme' 'libsoup3' 'webkit2gtk-4.1')
+optdepends=('docker: to actually run the sandboxed containers'
+            'xdg-utils: opening links from the app in your default browser')
+provides=('triple-c')
+conflicts=('triple-c')
+# !strip: the upstream .deb's binary is already the release build Tauri
+# produced and tested; re-stripping a prebuilt binary is unnecessary risk for
+# no benefit. !debug: there is no debug info in a release binary for
+# makepkg's debug-package machinery to extract, so without this it builds an
+# empty usr/src/debug/ tree for nothing (confirmed with namcap against a real
+# build — this was its only non-cosmetic complaint, once the license file
+# below was added).
+options=('!strip' '!debug')
+# Tauri names the asset after `productName` verbatim ("Triple-C"), not the
+# lowercase Cargo binary name — verified against the real release, not
+# assumed; a lowercase guess here would 404. The LICENSE fetch is separate
+# because the .deb itself carries no license file — namcap flags an MIT
+# package with nothing under /usr/share/licenses/ as an error, correctly.
+source=("Triple-C_${pkgver}_amd64.deb::https://github.com/shadowdao/triple-c/releases/download/v${pkgver}/Triple-C_${pkgver}_amd64.deb"
+        "LICENSE::https://raw.githubusercontent.com/shadowdao/triple-c/v${pkgver}/LICENSE")
+sha256sums=('SKIP'
+            'SKIP')
+
+package() {
+  cd "$srcdir"
+  # A .deb is an ar archive of debian-binary, control.tar.*, data.tar.* — `ar`
+  # (part of base-devel's binutils) pulls just the payload out. Extracting
+  # that tar directly into $pkgdir works here with no path rewriting at all:
+  # verified against the real archive, whose entire payload is
+  # usr/bin/triple-c, usr/share/applications/Triple-C.desktop and
+  # usr/share/icons/hicolor/*/apps/triple-c.png — Tauri's Linux bundle for
+  # this app carries no separate resource directory under usr/lib/, so there
+  # is nothing that could disagree between Debian's and Arch's package trees
+  # for it to land in the wrong place.
+  ar x "Triple-C_${pkgver}_amd64.deb"
+  tar xf data.tar.* -C "$pkgdir"
+
+  install -Dm644 "$srcdir/LICENSE" "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
+}

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.