chore: update Rust to 1.97.1

[imabdulbasit]

No description provided.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

[claude]

Claude finished @imabdulbasit's task in 1m 14s —— View job

---

Review: chore: update Rust to 1.97.1

• Read PR diff and gather context
• Review flake.lock Rust bump
• Review apply → apply_pair test changes
• Post review

This is a clean, low-risk chore PR. Both changes look correct.

flake.lock — bumps only the oxalica/rust-overlay input (lastModified, narHash, rev); no other flake nodes touched. Matches the stated 1.97.0 → 1.97.1 intent. ✅

crates/hotshot/new-protocol/src/tests/consensus.rs — the two edits are correct fixes, not just clippy appeasement:

• TestView::proposal_input_consensus returns a tuple (ConsensusInput, ConsensusInput) (utils.rs:154), while ConsensusHarness::apply takes a single ConsensusInput (utils.rs:1074). Passing the tuple to .apply() doesn't type-check, so these two sites (lines 853 and 912) were leftover breakage from Move proposal/VID-share pairing into Consensus. #4698 which moved proposal/VID-share pairing behind apply_pair. This PR correctly routes them through apply_pair (utils.rs:1082), which applies the proposal then the VID share.
• The change is consistent with every other proposal-application site in this file — all ~40 other proposal_input_consensus calls already use apply_pair (or manually destructure the pair for the low-level consensus.apply path). I confirmed via grep that no other .apply(...proposal_input_consensus...) sites remain, so these were the only two that needed fixing.
• Behavior is unchanged: the surrounding block_reconstructed_input / cert1_input sequence and assertions in both test_timeout_proposal_chains_from_lock_not_timed_out_cert1 and test_bridged_legacy_qc_adopts_lock_and_reproposes match the neighboring tests that already used apply_pair.

Notes

• No security, performance, or documentation surface here — test-only + toolchain pin.
• Worth confirming CI's nix-based clippy/build job passes on the new toolchain, since that's the surface the bump actually affects. I didn't run the full nix build locally.

No blocking issues from me. LGTM.