fix(ci): get the MSRV job and cargo-deny green again

.github/dependabot.yml

@@ -59,6 +59,21 @@ updates:
       actions:
         patterns:
           - "*"
+    # The MSRV job pins `dtolnay/rust-toolchain` by a ref that names a *Rust
+    # version*, not a release of the action. The updater cannot see that: it
+    # compares the numbers, finds 1.100.0 larger than 1.94.1, and pins a
+    # toolchain `rustup` then 404s on — which is what happened, and it failed
+    # every pull request in the repository at toolchain install. The floor is
+    # raised by hand, next to `rust-version` in the root Cargo.toml, which is
+    # the pairing the job's own comment asks for.
+    ignore:
+      - dependency-name: dtolnay/rust-toolchain
+    # This also stops the SHA pin in `signal-durability-nightly.yml` being
+    # refreshed, which is collateral rather than intent: an ignore is per
+    # dependency, not per use. That pin is a reproducibility anchor for a
+    # nightly job rather than a floor that has to track anything, so it going
+    # stale costs less than the MSRV job breaking every week. Bump it by hand
+    # if a fix in the action ever matters there.
 
   # No docker entry: the Dockerfile builds `FROM rust:alpine` and `FROM
   # scratch`, neither of which carries a version for the updater to bump. Add

.github/workflows/main.yml

@@ -429,7 +429,15 @@ jobs:
       # Pinned rather than `@stable`: this version is the workspace MSRV
       # (`rust-version` in the root Cargo.toml). To raise the floor, bump both
       # together — a floating `stable` would silently let the declared MSRV rot.
-      - uses: dtolnay/rust-toolchain@1.100.0
+      #
+      # And it is not Dependabot's to raise. This ref is a Rust version, not a
+      # release of the action, so the updater bumps it by comparing numbers and
+      # has no way to know the toolchain has to exist and has to match the
+      # declared floor. It once moved this to 1.100.0 — numerically the largest
+      # ref, a Rust release that does not exist — and every pull request in the
+      # repository failed at `rustup`, before a line was compiled. The
+      # `dependabot.yml` entry beside this one is what keeps the pin ours.
+      - uses: dtolnay/rust-toolchain@1.94.1
       # The pre-built nextest binary is toolchain-independent — it drives this
       # MSRV cargo the same way it drives the nightly one.
       - name: Install protoc and cargo-nextest

deny.toml

@@ -12,12 +12,16 @@ exclude-dev = true
 
 [advisories]
 version = 2
-# Only `unmaintained` notices are listed below, and only where no upgrade
-# exists. A real vulnerability advisory must be resolved by a version bump,
-# never by an entry here.
-ignore = [
-    { id = "RUSTSEC-2026-0150", reason = "audiopus_sys, reached through the optional `voip-libopus` feature via opus 0.3. Upstream is dormant with no fork on crates.io; the crate is a thin libopus FFI shim that we build but do not drive directly." },
-]
+# Only `unmaintained` notices belong here, and only where no upgrade exists. A
+# real vulnerability advisory must be resolved by a version bump, never by an
+# entry here.
+#
+# Empty on purpose. RUSTSEC-2026-0150 (audiopus_sys) was listed until the crate
+# left the graph entirely -- `audiopus` appears nowhere in Cargo.lock now, even
+# under `--all-features` -- and cargo-deny reports a stale ignore as
+# `advisory-not-detected`. An ignore outliving the crate it excuses is how a
+# real advisory gets waved through later under a name nobody rechecked.
+ignore = []
 
 [licenses]
 version = 2
@@ -75,6 +79,26 @@ skip = [
     { name = "getrandom", version = "=0.2.17" },
     { name = "rand_core", version = "=0.6.4" },
 
+    # Build-script-side duplicates, all reached only through `buffa-build`,
+    # which every crate that uses it declares under `[build-dependencies]`.
+    # Like the proc-macro entries below, they cost build time only: a build
+    # script runs at compile time and links into no shipped binary. And none of
+    # them can be collapsed from here, because each pair is two incompatible
+    # majors pulled by different parents -- the workspace is on `getrandom` 0.4
+    # via rand 0.10, while `tempfile` inside the codegen is on 0.3, and `r-efi`
+    # is simply whichever one each `getrandom` chose. Collapses when buffa
+    # upgrades, not on anything we can do to our own manifests.
+    #
+    # `Cargo.lock` invites a misreading here: it carries a `rand_core` 0.9.5
+    # entry that lists `getrandom 0.3.4` as a dependency, which reads like a
+    # second, runtime path into the shipped graph. Nothing reaches that
+    # rand_core -- `cargo tree -i rand_core@0.9.5 --target all` prints nothing
+    # at all -- so the lock entry is stale and the build-dependency route below
+    # is the only one. Check with `cargo tree -i`, not by grepping the lock.
+    { name = "getrandom", version = "=0.3.4" },
+    { name = "prettyplease", version = "=0.2.37" },
+    { name = "r-efi", version = "=5.3.0" },
+
     # Proc-macro-side duplicates. They cost build time only — proc macros run
     # at compile time and never link into the produced binary.
     { name = "darling", version = "=0.21.3" },