Retire the Arch package, document AppImage desktop integration

The `triple-c-bin` package was never on the AUR, so installing it meant
downloading a file and running `pacman -U` — the same gesture as making an
AppImage executable, for a second artifact to keep building. And being
`workflow_dispatch`-only it reached 1 release in 28 (only v0.4.16 has a
`.pkg.tar.zst`), while HOW-TO-USE.md told Arch and CachyOS users to download
it from every release. A distribution channel that is absent 27 times out of
28 is worse than not promising one.

`packaging/arch/` and `.gitea/workflows/publish-arch-package.yml` are
preserved whole on `hold/arch-packaging`, the same way the disk panel and
drag-out work were held rather than deleted. What would make an Arch package
worth having is an AUR account and its SSH key as a repo secret — both
one-time manual steps that never happened; the workflow's own header already
said as much about its AUR push step.

This also closes the gap that prompted the review: nothing validated the
PKGBUILD until someone manually dispatched the workflow, making it the only
packaging path with no CI coverage. Removing it removes the untested surface
rather than adding a job to test something nobody installs.

In its place, `scripts/install-appimage.sh` does what a package manager's
install hooks would. An AppImage carries a `.desktop` entry and icons inside
itself, but nothing on the host reads them, so it never appears in the app
launcher. The script extracts the bundled icons into the user's icon theme
and writes a launcher entry — no sudo, nothing outside `~/.local/share`, and
the AppImage itself is never copied or moved.

Two details it gets right on purpose:

  * The `Exec` line is rewritten, not copied. The bundled entry says
    `Exec=triple-c`, which resolves only inside the running AppImage's own
    mount — a verbatim copy gives a launcher entry that starts nothing.
  * Extraction uses `--appimage-extract`, which needs no FUSE, so the script
    works on a machine where *running* the AppImage would first need
    `fuse2` installed. That requirement is now documented too: Arch and
    CachyOS do not ship FUSE 2 by default.

Verified against the real artifact — the AppImage from this repo's own
preview-3a49a67 release: 4 icon sizes install, `desktop-file-validate` passes
with no warnings, `--uninstall` leaves nothing behind, and shellcheck is
clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ApLYH6ybHwQFkMCtKuHrrV

packaging/arch/PKGBUILD

@@ -1,86 +0,0 @@
-# Maintainer: Triple-C Contributors
-#
-# This file is regenerated by .gitea/workflows/publish-arch-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. It's also what actually suppresses makepkg's debug-package
-# machinery here (debug-package extraction requires strip; verified in a
-# real build — with !strip alone, no debug package is produced at all).
-# !debug is kept anyway, explicit about intent rather than relying on that
-# side effect. Without either, makepkg built a usr/src/debug/triple-c-bin
-# tree containing a dangling .build-id symlink, which is a real namcap
-# error (not just the empty-directory warning it looks like) — there is no
-# debug info in this release binary for the machinery to have extracted in
-# the first place.
-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.
-  #
-  # Globbed rather than named literally: the publish workflow discovers the
-  # real asset name from the release itself specifically so a Tauri bundler
-  # naming change can't silently break this — naming the file again here
-  # would throw that away and fail this one line with an opaque "No such
-  # file or directory" instead. `source=()` above guarantees exactly one
-  # `*_amd64.deb` entry, so the glob can only ever match that one file.
-  ar x ./*_amd64.deb
-  tar xf data.tar.* -C "$pkgdir"
-
-  install -Dm644 "$srcdir/LICENSE" "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
-}

packaging/arch/README.md

@@ -1,52 +0,0 @@
-# Arch / CachyOS package
-
-`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"
-
-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-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 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).
-
-**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
-
-`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.
-
-**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.