build(ci): cross-compile and publish an aarch64 Linux client

Adds punktfunk-rust-ci-arm64cross (the rust-ci toolchain + an Ubuntu ports
arm64 multiarch sysroot) and a deb.yml job that cross-builds the client
package on the ordinary amd64 runner — no arm64 runner in the fleet and
none needed. Client only: the Linux host encodes with NVENC/QSV/AMF, all
x86. The apt registry keys pool entries by the .deb's own arch, so an arm64
box picks the package up with no client-side configuration.

Three things this had to get right, each of which cost a failed build:

  * rustup target add must run against the toolchain rust-toolchain.toml
    PINS, not the image's default `stable` — otherwise the pinned toolchain
    has no aarch64 std and the build dies ~230 crates in on "can't find
    crate for core". Copying the pin file in also pre-downloads the
    toolchain every CI job currently re-fetches on first use.

  * ffmpeg-sys-next compiles a probe it intends to RUN, so it forces
    .target(HOST) while still passing the TARGET's include paths; the arm64
    dir then shadows the host's own libc headers and the x86 compiler dies
    in bits/math-vector.h on NEON/SVE types. Prepending the host dir does
    NOT help — GCC drops a -I that duplicates a system directory, keeping
    its original later position — so ci/pf-host-cc strips target include
    dirs from host compiles instead.

  * the job hard-fails on a non-AArch64 session binary, rather than
    shipping an amd64 payload under an arm64 package name.

skia needs no special handling: the aarch64-linux-gnu textlayout+vulkan
prebuilt resolves, so arm64 ships the FULL client, OSD included — unlike
Windows ARM64, which still builds --no-default-features.

The cross image builds in its own docker.yml job (needs: build-push) since
it is FROM punktfunk-rust-ci:latest and must not race the entry that
publishes that base. rpm/Arch/Flatpak stay x86_64 for now — their builders
have no arm64 sysroot, which is its own piece of work.

Plan: punktfunk-planning design/embedded-arm64-client.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ci/pf-host-cc

@@ -0,0 +1,45 @@
+#!/bin/bash
+# Host-side C compiler wrapper for the aarch64 cross image (ci/rust-ci-arm64cross.Dockerfile).
+#
+# Why this exists: ffmpeg-sys-next's build script compiles a probe it intends to RUN — it
+# executes the binary to read the libav* version macros — so it forces `.target(HOST)` with
+# the comment "don't cross-compile this", but still hands that host compile the TARGET's
+# pkg-config include paths. `-I/usr/include/aarch64-linux-gnu` then shadows the host's own
+# multiarch libc headers and the x86 compiler dies inside bits/math-vector.h on NEON/SVE
+# types it has never heard of.
+#
+# Prepending the host's multiarch dir does NOT fix it: GCC drops a `-I` that duplicates a
+# directory already on its system include path (keeping it in the original, later position),
+# so the arm64 dir stays in front. The reliable fix is to remove the target include dirs from
+# the host compile entirely — the probe only wants FFmpeg's version macros, and the amd64
+# libav*-dev headers are installed and on the default search path, at the same version (both
+# come from this Ubuntu release).
+#
+# Scope: only ever invoked as CC for the HOST triple (CC_x86_64_unknown_linux_gnu). Target
+# compiles go to aarch64-linux-gnu-gcc and never pass through here.
+set -euo pipefail
+
+declare -a out=()
+while (($#)); do
+  case "$1" in
+  # `-I dir` as two arguments — the form cc's Command building and ffmpeg-sys both emit.
+  -I)
+    if [[ ${2-} == *aarch64-linux-gnu* ]]; then
+      shift 2
+      continue
+    fi
+    out+=("$1" "${2-}")
+    shift 2
+    ;;
+  # `-Idir` glued into one argument.
+  -I*aarch64-linux-gnu*)
+    shift
+    ;;
+  *)
+    out+=("$1")
+    shift
+    ;;
+  esac
+done
+
+exec /usr/bin/cc "${out[@]}"