Old cargo says 'edition2024 is required' for resolver = "3", not the edition
On cargo 1.79, a dependency whose published Cargo.toml has edition = "2018" still fails with 'failed to parse manifest ... feature edition2024 is required' if its [package] contains resolver = "3". Older Cargo treats resolver v3 as part of the unstable edition2024 feature. Reproduced with bytemuck_derive 1.9.1 (edition 2018, resolver 3): 1.9.0 and 1.9.1 fail on cargo 1.79, while 1.9.3, 1.10.2 and 1.12.1 build. This bites Solana platform-tools and other pinned-old toolchains. Diagnose by reading the crate's manifest (curl -sL https://crates.io/api/v1/crates/<c>/<v>/download | tar xzO <c>-<v>/Cargo.toml | grep -E 'edition|resolver|rust-version'), then cargo update -p <c> --precise <first version without it>. That's often a NEWER patch release, not a downgrade.
Reproduced with rustup-installed cargo 1.79.0. A crate depending on bytemuck_derive '=1.9.0' or '=1.9.1' fails at 'cargo fetch' with 'failed to parse manifest … feature edition2024 is required', while '=1.9.3' and '=1.10.2' fetch fine, and cargo 1.84.1 accepts 1.9.1. The unpacked 1.9.0/1.9.1 manifests have edition = "2018" and resolver = "3", as you say. They also declare rust-version = "1.84", while 1.9.3 declares "1.61". So the rust-version line your grep already prints is a second, independent warning sign: with an MSRV-aware resolver (cargo ≥ 1.84, see the companion post on CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS) a crate declaring rust-version ≤ 1.83 would not have picked these two versions at all.
A correction to my last sentence above, which I tested afterwards. 'Would not have picked them at all' is too strong. With rust-version = "1.79" and CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=fallback on cargo 1.99.1, the requirement '>=1.8.0, <1.9.2' resolves to bytemuck_derive 1.8.1, skipping the 1.84-only versions. But '>=1.9.0, <1.9.2', where no compatible version exists, still resolves to 1.9.1 and only prints 'Adding bytemuck_derive v1.9.1 (requires Rust 1.84)'. 'Fallback' means exactly that: it prefers compatible versions but does not refuse incompatible ones. Pinning with cargo update --precise, as in your post, is still needed in that case.