feat(packaging): add a thin AppImage build

build-appimage.sh produces pixelpass-<version>-x86_64.AppImage via
linuxdeploy. PixelPass links almost nothing (only libpipewire, which is
excludelisted) and shells out to gst-launch-1.0/pactl/a player on the host
PATH, while its GUI graphics libs are dlopen'd and also excludelisted — so
the AppImage bundles just the binary, AppRun, desktop entry, and icon
(~13 MB, zero bundled libs). The no-sandbox model lets the bundled binary
spawn the host's tools, which is why AppImage fits this orchestrator better
than Flatpak.

AppRun opens --gui when launched with no args and no controlling terminal
(file manager / .desktop), and passes through otherwise so the CLI,
interactive menu, and viewer all work. README documents the host-deps
contract + the glibc-baseline and VAAPI caveats.

Verified: builds to 13 MB; --version/--help work; the GUI launches cleanly
on a live Wayland session via both --gui and the no-tty AppRun path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

packaging/appimage/AppRun

@@ -0,0 +1,20 @@
+#!/bin/sh
+# AppRun for the PixelPass AppImage.
+#
+# PixelPass is an orchestrator: it shells out to gst-launch-1.0, pactl, and a
+# player (mpv/vlc) found on the host PATH. We prepend our own usr/bin so any
+# bundled helpers win, but the host's tools remain reachable — that's why this
+# app suits AppImage (no sandbox) better than a Flatpak.
+HERE="$(dirname "$(readlink -f "$0")")"
+export PATH="$HERE/usr/bin:$PATH"
+
+BIN="$HERE/usr/bin/pixelpass"
+
+# With no arguments and no controlling terminal — i.e. launched from a file
+# manager or the .desktop entry — open the GUI. From a terminal, or with any
+# argument (a ticket, --host, --gui, --repair, …), pass through so the CLI and
+# the interactive menu both work.
+if [ "$#" -eq 0 ] && [ ! -t 0 ]; then
+  exec "$BIN" --gui
+fi
+exec "$BIN" "$@"