ci: bump mordant to 00778d3 so that the unused_pub count is stable

[robobun]

Problem

• The mordant job passes or fails at random at the pinned d0dca00. cargo mordant reports three associated constants of bun_sys::Tag two or three times each, so the unused_pub count for src/sys/lib.rs is 65 or 68 over the same code. The baseline records 65, and the first run on ci: bump mordant to d0dca00 #43805 counted 68.
• The cause is in mordant. It identified an item by a key that contains the index of its impl block. A cfg(windows) impl block shifts that index on Windows only, and mordant dropped a duplicate finding only when it sat next to its twin. The order of the three targets' records is the order in which cargo finishes them.

Fix

• MORDANT_REV moves to 00778d35391dc1a75381008754fd40726c1682f0 (Match and report an unused_pub item by its position, not by its key scarletindustries/mordant#29). It matches and reports an item by its position: crate, file, offset of the name. MORDANT_TOOLCHAIN stays nightly-2026-09-01.
• mordant-baseline.toml is regenerated and only goes down: src/sys/lib.rs 65 to 56, and the entries for src/io/lib.rs (1) and src/spawn_sys/spawn_process.rs (5) are gone.
• Verified: bun scripts/rust-mordant.ts is clean from an empty target/mordant, and clean again on a warm run. The mordant check on this PR is the CI proof.

Background

• The job checks three targets in one run, so each pub item is recorded up to three times. cargo mordant decides unused_pub after the build, from all of those records.
• The baseline holds a count per lint and file. A run fails when a count goes over.

Notes

What changes in the findings, measured over this tree with no baseline:

• 18 items are no longer reported. Each has a use under one target, and the other targets' records of the same item had a different key, so the use did not count for them. Examples: Tag::epoll_ctl (Linux), Tag::uv_spawn (Windows), FilePollRef::set_flag, ExtraPipe::fd.
• The three Tag constants that were reported two or three times are reported once.
• Six more reports appear, all in src/sys/lib.rs, for items that share a name under different cfgs, such as O::NOATIME, which is defined at three places. Each is a separate unused item. The old key was the same for all of them, so they were merged into one finding.
• In total 188 reports become 173.

---

no test proof · iteration 0 · no src or test change; test-proof not applicable

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 2 billable files and costs up to $0.50.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 8 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: oven-sh/bun/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Essentials

Run ID: 5e38b746-31d3-41c3-9b2f-027e4591b95d

📥 Commits

Reviewing files that changed from the base of the PR and between ce4d569 and e3d1fc4.

📒 Files selected for processing (2)

• .github/workflows/rust-lints.yml
• mordant-baseline.toml

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: merged.

• Requested in chat by @alii after Match and report an unused_pub item by its position, not by its key scarletindustries/mordant#29 merged. ci: bump mordant to d0dca00 #43805 was merged before this update was pushed to it, so this PR carried the pin to 00778d3.
• Verified locally at 00778d35391dc1a75381008754fd40726c1682f0: bun run rust:mordant:baseline wrote the baseline in this PR, and it only goes down.
• bun scripts/rust-mordant.ts from an empty target/mordant is clean (three targets), and clean again on a warm run.
• CI proof: the mordant check passed on the runner in 3m45s (job). It counted the same as the regenerated baseline: nothing over.

[claude]

LGTM, a straightforward CI pin bump with a decrease-only baseline regeneration.

What was reviewed:

• The bump follows the procedure in .github/workflows/CLAUDE.md (MORDANT_REV changed, MORDANT_TOOLCHAIN kept); the binary cache key at rust-lints.yml:167 includes the rev, so stale mordant binaries cannot be restored.
• The baseline deltas (-9 in src/sys/lib.rs, -1 src/io/lib.rs, -5 src/spawn_sys/spawn_process.rs = 15) match the description's 188 to 173 total, consistent with a regenerated file rather than a hand edit.
• No stale references to the old revision remain in the repo; the job is advisory, so a lost per-target entry would surface as a warning on the PR check, not a blocked merge.

Extended reasoning...

The PR changes two files: the pinned mordant revision in the advisory mordant job of .github/workflows/rust-lints.yml, and mordant-baseline.toml, where three unused_pub entries shrink or disappear and no count increases. It touches no Rust source, no runtime code, and no security-sensitive surface. The removed baseline counts sum exactly to the difference the description reports, the cache key already covers both pin values, the job is continue-on-error so the worst case is a visible warning, and neither path is covered by .github/CODEOWNERS. I could not fetch mordant's rust-toolchain file at the new revision to independently confirm the nightly is unchanged, but a mismatch would fail the PR's own mordant check at the cargo install step rather than silently pass.