ci: pin the toolchain to 1.98.1 in all three jobs

All three jobs used `dtolnay/rust-toolchain@stable`, so the gate resolved to
whatever stable was on the day it ran. A floating lint gate is not a gate: the
same tree goes green or red by date, and that already produced a disagreement
between two people reading the same commit — `collapsible_else_if` is `warn` on
1.92.0 and `allow`-by-default pedantic on 1.98.1, so both readings were correct.

1.98.1 is what run 206 resolved and what `docker/ci/Dockerfile` already pins, so
`docker/ci/run cargo clippy …` on a desktop becomes a true stand-in for this
workflow instead of an approximation. The header says how to bump: the three
refs here and the Dockerfile's `FROM` in one commit, in a PR of its own, where
the lints the new version turns on are the diff.

Also: the corpus-report step's comment quoted `207/0/14`, a tally two baselines
old. It now describes the shape of the problem without pinning a number that
decays.

Closes #15.

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

.github/workflows/ci.yml

@@ -31,6 +31,24 @@ env:
 # So: one job, on the machine that exists, building for the machine that exists.
 # If a second architecture is ever wanted here it needs a second RUNNER, not a
 # second matrix row.
+#
+# ── The toolchain is PINNED, in three places, deliberately ───────────────────
+#
+# All three jobs used `dtolnay/rust-toolchain@stable`, which resolves to whatever
+# stable is on the day the job runs. A lint gate that floats is not a gate: the
+# same tree goes green or red depending on the date, and this repo has already
+# produced a disagreement between two people reading the same commit (#15).
+# `collapsible_else_if` is the example — `warn` on 1.92.0, `allow`-by-default
+# pedantic on 1.98.1, so a clean local run and a red CI run were both correct.
+#
+# `1.98.1` is the version run 206 resolved, and `docker/ci/Dockerfile` pins the
+# same one, so `docker/ci/run cargo clippy …` on a desktop is a true stand-in for
+# this workflow rather than an approximation of it.
+#
+# To bump: change all three `dtolnay/rust-toolchain@` refs here AND the `FROM
+# rust:<version>-bookworm` in `docker/ci/Dockerfile` in one commit, so the two
+# can never drift apart silently. A bump is a change to the gate and belongs in
+# its own PR, where the new lints it turns on are the diff.
 
 jobs:
   # ── Native build, on the one runner there is ────────────────────────────────
@@ -42,13 +60,15 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: Install Rust toolchain
-        # `stable` installs a MINIMAL profile: rustc, cargo, rust-std and no
+        # Pinned — see the toolchain note at the top of this file.
+        #
+        # This action installs a MINIMAL profile: rustc, cargo, rust-std and no
         # more. Components have to be named. Without this line the Clippy step
         # below dies on "'cargo-clippy' is not installed for the toolchain
         # 'stable-aarch64-unknown-linux-gnu'" — which is not a lint result, it
         # is the step never having run. The `fmt` job below always got this
         # right; this one never did.
-        uses: dtolnay/rust-toolchain@stable
+        uses: dtolnay/rust-toolchain@1.98.1
         with:
           components: clippy
 
@@ -78,7 +98,7 @@ jobs:
         run: cargo test --workspace
 
       # The tally above cannot tell you what it verified. `cargo test` reports
-      # the same 207/0/14 whether the disc corpus was exercised or entirely
+      # the same count whether the disc corpus was exercised or entirely
       # absent -- a gated suite that skips still counts as passed, and the
       # `ignored` column is a static count of `#[ignore]` attributes that cannot
       # move at runtime. Issue #16. This prints what the run ACTUALLY had, from
@@ -114,7 +134,7 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: Install Rust toolchain + WASM target
-        uses: dtolnay/rust-toolchain@stable
+        uses: dtolnay/rust-toolchain@1.98.1
         with:
           targets: wasm32-unknown-unknown
 
@@ -161,7 +181,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: dtolnay/rust-toolchain@stable
+      - uses: dtolnay/rust-toolchain@1.98.1
         with:
           components: rustfmt
       - run: cargo fmt --all -- --check

docker/ci/run

@@ -21,51 +21,18 @@ IMAGE="${SYLPH_CI_IMAGE:-sylph-ci:local}"
 CPUS="${SYLPH_CI_CPUS:-6}"
 MEM_GB="${SYLPH_CI_MEM_GB:-7}"
 
-CARGO_VOL="${SYLPH_CI_CARGO_VOL:-sylph-ci-cargo}"
-TARGET_VOL="${SYLPH_CI_TARGET_VOL:-sylph-ci-target}"
-
-# 🔴 Docker on the dev boxes is ROOTFUL, so without `--user` every byte the build
-# writes into the bind-mounted repo is owned by root — and the user then needs
-# `sudo` to delete their own artifacts. The regen command in the workspace
-# `CLAUDE.md` writes `sylpheed.db` straight into /work, so it lands root-owned,
-# and a stray root-owned file is exactly what survived the last cleanup and had
-# to be sudo'd away.
-#
-# The catch is that the daemon creates a named volume root-owned, so a `--user`
-# container cannot write /cargo or /target at all. Take ownership once — and
-# only when it is actually wrong, because a recursive chown across a ~36 GB
-# target volume is not something to repeat on every invocation.
-RUN_UID="$(id -u)"
-RUN_GID="$(id -g)"
-
-docker volume create "$CARGO_VOL"  >/dev/null
-docker volume create "$TARGET_VOL" >/dev/null
-
-# Both volumes, not just one: they are chowned together but can drift apart if an
-# older root-owned run created only one of them.
-vol_owner="$(docker run --rm -v "$CARGO_VOL:/cargo" -v "$TARGET_VOL:/target" "$IMAGE" \
-             stat -c %u /cargo /target 2>/dev/null | sort -u | tr '\n' ' ' || echo unknown)"
-if [ "$vol_owner" != "$RUN_UID " ]; then
-  echo "docker/ci/run: chowning the cargo/target volumes to $RUN_UID:$RUN_GID (one-off)" >&2
-  docker run --rm \
-    -v "$CARGO_VOL:/cargo" -v "$TARGET_VOL:/target" \
-    "$IMAGE" chown -R "$RUN_UID:$RUN_GID" /cargo /target
-fi
-
 args=(
   --rm
   --cpus "$CPUS"
   --memory "${MEM_GB}g"
   --memory-swap "${MEM_GB}g"
   --pids-limit 2048
-  # Run as the invoking user so build output in /work is owned by them, not root.
-  --user "$RUN_UID:$RUN_GID"
   -v "$REPO:/work"
   # Named volumes, not bind mounts: the host tree keeps a 32 GB `target/` from
   # earlier host-side builds, and mixing the two produces rebuilds that look
   # like cache misses and are actually two toolchains fighting over one directory.
-  -v "$CARGO_VOL:/cargo"   -e CARGO_HOME=/cargo
+  -v sylph-ci-cargo:/cargo   -e CARGO_HOME=/cargo
-  -v "$TARGET_VOL:/target" -e CARGO_TARGET_DIR=/target
+  -v sylph-ci-target:/target -e CARGO_TARGET_DIR=/target
   -w /work
 )