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/README.md

@@ -0,0 +1,41 @@
+# PixelPass AppImage
+
+A "thin" AppImage: the gui-enabled `pixelpass` binary, a launcher (`AppRun`),
+and the desktop entry + icon. Run `./build-appimage.sh` to produce
+`pixelpass-<version>-x86_64.AppImage`.
+
+## Why thin
+
+`pixelpass` is an orchestrator — it links almost nothing (only `libpipewire`,
+which is excludelisted because it must match the host daemon) and instead
+**shells out** to `gst-launch-1.0`, `pactl`, and a player (`mpv`/`vlc`) found on
+the host `PATH`. The GUI's graphics libraries (`libGL`, `libwayland-*`,
+`libxkbcommon`, X11) are dlopen'd at runtime and are likewise on the AppImage
+excludelist — every desktop already has a matching set. So there is nothing
+useful to bundle, and bundling the graphics stack would only risk driver
+mismatches. The AppImage therefore carries just the binary.
+
+This also explains why PixelPass suits AppImage better than Flatpak: the
+no-sandbox model lets the bundled binary freely spawn the host's `gst-launch`,
+`pactl`, and player, which a Flatpak sandbox would block.
+
+## Host requirements
+
+The AppImage runs on any reasonably current glibc-based distro that has:
+
+- **GStreamer + plugins** — `gst-launch-1.0`/`gst-inspect-1.0` plus base,
+  good/bad/ugly, libav, and the PipeWire plugin (the binary tells you the exact
+  package names for your distro if something is missing).
+- **PipeWire** (with the PulseAudio shim, for `pactl`).
+- **A player** — `mpv` (preferred) or `vlc` — for the viewer side.
+- For X11 single-window capture: `xwininfo`.
+
+These are the same dependencies the Arch package lists; the AppImage just spares
+you the Rust toolchain.
+
+## Caveats
+
+- **Built on a bleeding-edge glibc** (CachyOS), so the AppImage requires a host
+  glibc at least that new. For broad compatibility, rebuild on an older base.
+- **Hardware encode (VAAPI `vah264enc`)** uses the host GPU driver; it can't be
+  bundled. The software path (`--no-hwencode`, x264) always works.