Skip AUR for now — attach the built Arch package to the GitHub release

Publishing to the AUR needs a maintainer AUR account and its SSH key
registered as a secret here, neither of which exists yet. Rather than
leave the workflow permanently failing at that last step, it now stops
short of AUR and instead uploads the built .pkg.tar.zst to the same
GitHub release it built from, as a plain downloadable asset (`pacman -U`
to install). The AUR-push step is still in this file's git history if
that setup happens later.

Renamed publish-aur-package.yml -> publish-arch-package.yml to match.
The render/validate steps are unchanged; new here is capturing the exact
built package filename from inside the build container (makepkg is the
only thing that actually knows it) and an upload step that follows the
same create-or-reuse-release, strip-upload_url, POST-octet-stream pattern
build-app.yml and backfill-releases.yml already use for GitHub assets,
plus a delete-existing-asset-first step so a re-dispatch for an
already-packaged version replaces rather than 422s.

Verified with a real Docker run end to end: rendered a real PKGBUILD,
built a real (synthetic) .deb through makepkg + namcap in an archlinux
container, confirmed the container exits 0, and confirmed the exact
package filename it captures (triple-c-bin-<version>-1-x86_64.pkg.tar.zst)
round-trips out via docker cp intact.

packaging/arch/README.md

@@ -1,7 +1,9 @@
 # Arch / CachyOS package
 
-`PKGBUILD` here is the AUR `triple-c-bin` package's template — see triple-c#34
+`PKGBUILD` here is the `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).
+It's written to AUR conventions (and may go there eventually — see
+"Publishing" below) but isn't published to the AUR yet.
 
 ## Why "-bin"
 
@@ -18,24 +20,23 @@ to be real dependencies of *this* binary and were dropped), and ran a real
 
 ## Publishing
 
-`.gitea/workflows/publish-aur-package.yml` does the actual work: given a
+`.gitea/workflows/publish-arch-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.
+`namcap` inside a real Arch container, and attaches the resulting
+`.pkg.tar.zst` to that same GitHub release as a downloadable asset —
+installable by hand with `sudo pacman -U`.
 
 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.
+**Not on the AUR yet.** Publishing there would need a maintainer AUR account
+and its SSH key added as a secret on this repo — both manual, one-time steps
+on https://aur.archlinux.org that only a maintainer can do. The workflow's
+git history still has the AUR-push step from before this was descoped, if
+that setup happens later and it's worth reinstating.
 
 ## What's hand-maintained vs. generated
 
@@ -45,9 +46,7 @@ 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.
 
-**A hand-edit made directly in the AUR repo is silently overwritten the
-next time this workflow runs.** Every run renders fresh from *this*
-repo's template rather than starting from whatever AUR's copy currently
-looks like, so a quick fix pushed straight to AUR (bumping `pkgrel` for a
-packaging-only issue, say) survives only until the next dispatch. Make
-the fix here instead.
+**A hand-edit made to the rendered PKGBUILD attached to a GitHub release is
+not this file.** Every run renders fresh from *this* repo's template, so a
+packaging fix belongs here, not in a downloaded copy — the next dispatch for
+that version would just overwrite it anyway.