CI: replace from-source libadwaita build with pinned Arch container

The dev/rc/release workflows rebuilt libadwaita from source inside an
uncached Fedora container on every single run, because Ubuntu 24.04's
packaged libadwaita was too old for gtk4 0.11's v4_12 feature. That
from-source build broke repeatedly on drift (rust dep versions,
libadwaita ABI, and finally a removed meson option), producing eight
straight failed CI runs.

Arch's repos already carry current gtk4/libadwaita/gtk4-layer-shell as
prebuilt packages, and breadpad only targets BOS/Arch, so there's no
reason to build anything from source. Swap the container base to a
digest-pinned archlinux image (ci/Containerfile) with those packages
installed via pacman, and extract the shared "build the image, run
cargo inside it" logic into ci/build.sh so it isn't duplicated three
times across the workflows. Cargo's registry/git/target caches persist
in named docker volumes across runs.

Also:
- Add check.yml: clippy + test on feature/**/fix/** pushes, so lint/
  build breakage surfaces before it reaches main and triggers a
  dev-track release.
- Fix release.yml's tag trigger (tags-ignore) so an rc tag push no
  longer also spawns a skipped release.yml run alongside rc-release.yml.

Verified locally: the container builds cleanly via pacman (no source
compilation), and `cargo build --release --locked --workspace` inside
it produces working breadpad/breadman binaries linked against
libgtk4-layer-shell.so.0 and libadwaita-1.so.0 respectively.

ci/Containerfile

@@ -0,0 +1,22 @@
+# Pinned CI build environment for breadpad.
+#
+# Arch instead of Fedora because breadpad targets BOS/Arch only, and Arch's
+# repos already carry current libadwaita/gtk4/gtk4-layer-shell as prebuilt
+# packages — no from-source libadwaita build needed (that from-source build
+# was the repeated CI breakage: rust dep mismatches, libadwaita ABI
+# mismatches, and finally a removed meson option).
+#
+# Base image pinned by digest, package set frozen at build time: this image
+# only changes when someone deliberately rebuilds it, not on every push.
+FROM archlinux@sha256:fae033b815a16f930325c2697e620362be4d2e5d739a301b10ad1fc9c8643a06
+
+RUN pacman -Syu --noconfirm --needed \
+        base-devel \
+        git \
+        pkgconf \
+        rust \
+        gtk4 \
+        libadwaita \
+        gtk4-layer-shell \
+        graphene \
+    && pacman -Scc --noconfirm

ci/build.sh

@@ -0,0 +1,31 @@
+#!/usr/bin/env bash
+# Builds (or reuses, via docker's own layer cache) the pinned Arch CI image
+# from ci/Containerfile, then runs the given cargo command inside it against
+# this repo checkout.
+#
+# Cargo's registry/git caches and CARGO_TARGET_DIR are persisted in named
+# docker volumes so they survive across runs even though the repo checkout
+# itself (a fresh --depth 1 clone per workflow run) does not.
+#
+# Usage: ci/build.sh cargo build --release --locked
+set -euo pipefail
+
+ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+cd "$ROOT"
+
+docker build -t breadpad-ci:archlinux -f ci/Containerfile ci
+
+docker run --rm \
+    -v "${ROOT}:/workspace" \
+    -v breadpad-cargo-registry:/root/.cargo/registry \
+    -v breadpad-cargo-git:/root/.cargo/git \
+    -v breadpad-cargo-target:/cargo-target \
+    -w /workspace \
+    -e CARGO_TARGET_DIR=/cargo-target \
+    breadpad-ci:archlinux \
+    bash -c '
+        set -euo pipefail
+        "$@"
+        mkdir -p /workspace/target
+        cp -a /cargo-target/. /workspace/target/
+    ' bash "$@"