chore: bump Rust toolchain from 1.89.0 to 1.97.1

[perryqh]

Summary

• Bumps the pinned toolchain in rust-toolchain.toml from 1.89.0 (Aug 2025) to 1.97.1, an eight-release jump.
• Clears 8 sites that trip a clippy lint newly widened in 1.97, which would otherwise fail the clippy job.

Context

• The pin had drifted roughly a year behind stable, so local builds on a current toolchain no longer matched the pinned one.
• No consumer-facing contract changes: Cargo.toml declares no rust-version, so this repo has no MSRV to bump. rust-toolchain.toml governs builds in this repo only.

Reviewer guidance

Two commits, deliberately split so the substantive change is a one-liner:

• d03f8d8 — the actual bump. One line in rust-toolchain.toml.
• a203f39 — mechanical lint cleanup. Applied with cargo clippy --fix; skimmable.

Rust 1.97 widens clippy's useless_borrows_in_formatting to flag & on Display-able expressions in format arguments. CI builds with RUSTFLAGS=-Dwarnings, so these became hard errors. Every fix removes a borrow and nothing else — &Cow<str> and Cow<str> have identical Display behavior, so there is no behavioral change and no new test surface.

Affected: src/cli.rs, src/runner.rs (5 sites), src/ownership/validator.rs, tests/common/mod.rs.

Notes

• d03f8d8 does not pass clippy on its own — the fixes land in a203f39. CI runs against the PR head so this is not an issue, but a git bisect landing exactly on that commit would see clippy failures. Happy to squash if preferred.
• Unrelated pre-existing gap, left alone: rust-toolchain.toml omits aarch64-unknown-linux-gnu from targets, though CI cross-builds it. cross supplies its own targets, so it works today.

🤖 Generated with Claude Code

[dduugg]

Approving. I verified the claims by running them rather than reading the diff, and they hold up.

Verified

• RUSTFLAGS=-Dwarnings cargo clippy --all-targets --all-features and cargo fmt --all -- --check pass clean at the head (a203f39).
• Checked out the bump-only commit (d03f8d8) and reran clippy: it fails with exactly the useless_borrows_in_formatting errors described (validator.rs:250, runner.rs:92/94/101/107/253), citing the rust-1.97.0 clippy docs anchor. The "the fix commit is required" framing is accurate.
• Ran clippy under the outgoing 1.89.0 against those same sites on base main: zero hits. So the lint genuinely widened between 1.89 and 1.97 — these were not pre-existing warnings.
• All 8 & removals are behavior-neutral. Each is either &Cow<str> -> Cow<str> from to_string_lossy(), or a borrow of a local temporary (&messages, &cache_dir.display()) not reused afterward. Display forwards through references at any depth, and the underlying calls only borrow self, so there is no move or reuse hazard.
• No rust-version in Cargo.toml; no dist-workspace.toml, cargo-dist config, clippy.toml, or dependabot config anywhere in the repo. Nothing else referenced a Rust version that needed to move.
• The aarch64-unknown-linux-gnu omission from targets is genuinely pre-existing, and the cross explanation checks out: upload-linux-bin runs cargo install cross then cross build --target aarch64-unknown-linux-gnu, which supplies its own target support independent of rustup's list.
• audit.yml already sets RUSTUP_TOOLCHAIN=stable with a comment about exactly this drift, so it is unaffected.

Nothing blocking, and no nits in the code itself. Two small notes inline.

[dduugg]

Two notes on this line, neither blocking.

1.97.1 is now one release behind stable. 1.98.0 shipped 2026-08-18, so the PR description's "1.97.1, an eight-release jump" is right but "current stable" language elsewhere in this series has already aged. Pinning one behind stable is a perfectly defensible choice — just flagging that the pin is no longer the newest if the intent was to land on current.

Commit-order convention differs from the sibling PR. rubyatscale/pks#57's toolchain bump (#52) deliberately lands the lint fixes first so every commit passes clippy independently and git bisect never lands on a red commit. This PR lands the bump first and notes d03f8d8 fails clippy on its own. Same author, same day, same lint, opposite call. Both are reasonable in isolation; worth picking one convention across the two repos so the next bump doesn't have to re-decide. (You already offered to squash — that would resolve it here.)