libva: fix runner label — actrunner-debian-aarch64-bohr

The previous commit used `debian-aarch64-bohr` for the runs-on
label, but the actual registered label is the full
`actrunner-debian-aarch64-bohr` (per @marfrit on the PR thread).
Without the `actrunner-` prefix the job would have sat in the queue
forever waiting for a runner that doesn't exist.

Renames the label in three places:

  - .gitea/workflows/build.yml — the runs-on directive itself.
  - debian/.../build-deb.sh — the comment referencing the expected
    runner, and the error message printed when the ABI sanity check
    trips (so a future debug session lands on the right runner name).
  - debian/.../changelog — the -2 entry's prose description.

Pure label rename; no behavioral or build-graph change.

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

.gitea/workflows/build.yml

@@ -976,7 +976,7 @@ jobs:
     # __vaDriverInit_1_23, which trixie's libva 2.22 runtime cannot bind: the
     # .deb installed but vaInitialize() returned -1 on every host.  A native
     # trixie runner avoids the cross-distro ABI skew entirely.
-    runs-on: debian-aarch64-bohr
+    runs-on: actrunner-debian-aarch64-bohr
     continue-on-error: true
     steps:
       - uses: actions/checkout@v4

debian/libva-v4l2-request-fourier/build-deb.sh

@@ -44,7 +44,7 @@ meson compile -C build
 # ABI sanity check: the produced .so MUST export __vaDriverInit_1_<MINOR>
 # matching the install target's libva runtime.  Build is expected to run on
 # a Debian trixie runner where <va/va.h>'s VA_MINOR is 22 — see
-# .gitea/workflows/build.yml (runs-on: debian-aarch64-bohr).  If a future
+# .gitea/workflows/build.yml (runs-on: actrunner-debian-aarch64-bohr).  If a future
 # runner change lands the build on a host with a different libva-dev
 # version, the produced symbol won't bind on the install target and ffmpeg/
 # vainfo/firefox-vaapi will all fail with "has no function
@@ -55,7 +55,7 @@ SO=$(find build -name 'v4l2_request_drv_video.so' | head -1)
 if ! nm -D --defined-only "$SO" | grep -q '__vaDriverInit_1_22'; then
     echo "FATAL: built driver does not export __vaDriverInit_1_22."
     echo "    Build host's <va/va.h> VA_MINOR_VERSION is likely != 22."
-    echo "    Expected runner: debian-aarch64-bohr (trixie, libva 2.22)."
+    echo "    Expected runner: actrunner-debian-aarch64-bohr (trixie, libva 2.22)."
     echo "    Symbol exports found:"
     nm -D --defined-only "$SO" | grep -i vadriverinit || echo "    (none)"
     exit 1

debian/libva-v4l2-request-fourier/debian/changelog

@@ -1,6 +1,6 @@
 libva-v4l2-request-fourier (1.0.0+r378+gc332d34-2) bookworm trixie; urgency=medium
 
-  * Rebuild on a native Debian trixie runner (debian-aarch64-bohr) so
+  * Rebuild on a native Debian trixie runner (actrunner-debian-aarch64-bohr) so
     the driver picks up trixie's libva-dev (2.22) and exports
     __vaDriverInit_1_22 — the symbol trixie's libva runtime looks up.
     Previous -1 build used the Arch CI runner (libva 2.23.0) and
@@ -9,7 +9,7 @@ libva-v4l2-request-fourier (1.0.0+r378+gc332d34-2) bookworm trixie; urgency=medi
     and ffmpeg -hwaccel vaapi fails on startup.
   * No source change; pure build-env fix.  CI workflow's
     libva-v4l2-request-fourier-debian job moved from runs-on:
-    arch-aarch64 to runs-on: debian-aarch64-bohr; build-deps installed
+    arch-aarch64 to runs-on: actrunner-debian-aarch64-bohr; build-deps installed
     via apt-get instead of pacman.
   * Hard sanity check kept in build-deb.sh: build fails if the
     resulting .so doesn't export __vaDriverInit_1_22 (preempts the