ci: bump mordant to 52896c0

.github/workflows/CLAUDE.md

@@ -135,7 +135,7 @@ Four independent jobs over the Rust workspace. They share `.github/actions/rust-
 
 - The pin is two values in the `mordant` job's `env:`: `MORDANT_REV` (a mordant commit) and `MORDANT_TOOLCHAIN` (the nightly in mordant's `rust-toolchain` file at that commit).
 - `mordant.toml` at the workspace root is the configuration. Mordant reads only its `[mordant]` table, which points `baseline` at `mordant-baseline.toml` (per-(lint, file) counts of the findings that predate the job) and lists the lints this repo has switched off under `disabled`, each with its reason.
-- In baseline mode mordant prints findings over the baseline as warnings and writes them to `target/mordant/over-baseline.txt` (relative to the workspace root). The job deletes that file, runs `cargo mordant`, and fails if the file is non-empty; absent or empty means clean. Fixing baselined findings needs no baseline update.
+- The baseline holds a count for each lint and file, not which findings. A file within its count prints nothing. A file that goes over prints every finding of that lint as a warning, followed by one line with the number found and the number the baseline allows: the new finding is among them, and it need not be the last one in the file. Mordant writes each crate that went over, with how many findings over, to `target/mordant/over-baseline.txt` (relative to the workspace root). The job deletes that file, runs `cargo mordant`, and fails if the file is non-empty; absent or empty means clean. Fixing baselined findings needs no baseline update.
 - `unused_pub` is the one lint that `cargo mordant` decides itself, after cargo is done. Each compilation records the `pub` items it defines and the workspace items it uses under `target/mordant/unused_pub/`, and `cargo mordant` judges the records of the units the run built. Its baseline entries sit in the section of the crate that defines the item. A use counts only from a target the run builds, and a member is judged only when the run leaves out no member that depends on it: a run under `-p` says little, and the job and the scripts pass `--workspace`. `scripts/rust-mordant.ts` names three triples (`x86_64-unknown-linux-gnu`, `x86_64-pc-windows-msvc`, `aarch64-apple-darwin`), so a use under `cfg(windows)` or `cfg(target_os = "macos")` counts; the host must be named too, since any `--target` drops it. The job and both package.json scripts go through that file, so the list is in one place. The job does not pass `--all-targets`, so an item that only tests use is reported. Passing it needs every test target in the workspace to compile on mordant's nightly, which no other CI job checks.
 - The baseline file and `MORDANT_BASELINE_WRITE` are inputs of every member's compilation: mordant's driver names them in the dep-info. So a baseline write, or a change to `mordant-baseline.toml`, re-lints every member on the next run, and a warm `target/mordant/check` is safe to keep. One thing differs on a warm run where nothing changed: cargo replays a crate's warnings and does not run the driver, so that crate does not append to `over-baseline.txt` again (`unused_pub` is judged again on every run). Locally, read the warnings. The file is for CI, which always starts cold.
 - Every other lint is counted per rustc process, so a file compiled under three triples is weighed against its recorded count three times, not summed. A baseline write is different: each process rewrites its crate's whole section, so over several `--target`s the last target to finish a crate wins and an entry only another target sees can be dropped. So `bun run rust:mordant:baseline` does not write in one run: the script writes one baseline per target, keeps the largest count for each entry, and takes the `unused_pub` entries from a fourth run over all three targets, the only kind that sees every use. Four runs, about four minutes on 16 cores.

.github/workflows/rust-lints.yml

@@ -132,7 +132,7 @@ jobs:
       # The pinned commit of https://github.com/scarletindustries/mordant.
       # Bumping it is a PR of its own, where whatever the new revision finds
       # gets fixed or added to mordant-baseline.toml.
-      MORDANT_REV: 00778d35391dc1a75381008754fd40726c1682f0
+      MORDANT_REV: 52896c0cc7c1751bbe29672dbc1f007d7d52f3f3
       # The nightly in mordant's rust-toolchain file at MORDANT_REV. mordant is
       # built with it and links its rustc, so it is also the compiler that
       # checks this workspace while the lints run, and it must still be able