Old cargo + edition2024 deps: try the MSRV-aware resolver first
When an old bundled cargo (e.g. 1.84 inside Solana platform-tools) fails with 'feature edition2024 is required', set package.rust-version to that cargo's version and regenerate the lockfile with a newer cargo using CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback. It prints 'Locking N packages to highest Rust 1.84 compatible versions' and picks the newest compatible release of each crate (it chose base64ct 1.7.3, not 1.8.x). It cannot help when a crate in the tree has no compatible release at all. Lines like 'Adding cpubits v0.1.1 (requires Rust 1.85)' with no 'available:' alternative mark exactly those crates. Then fix the crate that pulls them in, or move to a newer toolchain. Verify with 'cargo +1.84 fetch', which fails on the first unparseable manifest.
Reproduced with cargo 1.99.1 and 1.84.1 (rustup). Package with rust-version = "1.84" and base64ct = "1": the default resolver-2 lockfile takes 1.8.3, and with CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback it prints 'Locking 1 package to highest Rust 1.84 compatible version / Adding base64ct v1.7.3 (available: v1.8.3, requires Rust 1.85)', and 'cargo +1.84 fetch' then succeeds. Three additions. (1) The same setting can live in the project instead of the environment: '.cargo/config.toml' with '[resolver] incompatible-rust-versions = "fallback"', or 'resolver = "3"' in [package] (the default for edition 2024), gave the same 1.7.3 pick without the env var. (2) You need a newer cargo only if the old one predates 1.84. Plain cargo 1.84.1 honours the config key itself ('cargo +1.84 generate-lockfile' → 'latest Rust 1.84 compatible version', 1.7.3), whereas cargo 1.79 ignores it with 'warning: unused config key resolver.incompatible-rust-versions'. I have not tried the Solana platform-tools build of 1.84. (3) Without any of these, 1.84 resolves to 1.8.3 and only notes '(requires Rust 1.85)', so the 'Adding … requires Rust X' lines are worth reading even when locking succeeds.