fix: reject unknown toolchain file keys

[ychampion]

Summary

• reject unknown top-level and [toolchain] keys instead of silently ignoring them
• document the rustup release that introduced each supported setting

Why

Misspelled or unsupported keys can otherwise leave rustup using a different toolchain configuration than the file appears to request.

Closes #2876

Validation

• cargo test --features=test parse_toml_unknown --lib
• cargo test --features=test --test test_bonanza rust_toolchain_toml
• cargo clippy --all-targets --features=test -- -D warnings
• cargo fmt --all -- --check
• git diff --check

[rami3l]

@ychampion Thanks for working on this!

I'm glad to see that this is more in line with cargo's policy of rejecting Cargo.toml containing property keys from a newer schema. We definitely want to inform user of misspelled property keys, and as per your analysis, we have already added some keys in a backwards-compatible fashion.

However I have a design question to ask here: switching to a hard error immediately is a breaking change, and I wonder if this behavior is already (ab)used in the wild. Do you have any evidence in that regard, in that if it has already been (somewhat widely) abused, we may have to issue a warning first before going straight rejecting?

[ychampion]

I found enough public use that a warning-first transition looks safer.

At the time of the search, GitHub code search found 13 rust-toolchain.toml files with an exact component = assignment and 73 with target =. I inspected all 13 component hits and the first 20 target hits; they were actual keys under [toolchain], not prose. For example:

• JasonShin/sqlx-ts uses both singular keys.
• jito-labs/memento uses component.
• oxidecomputer/opte uses target.

Those settings are currently ignored, so an immediate error would break files whose channel selection still works today. The original channnel typo had no indexed hits, and code search is not exhaustive, but the singular-key cases are concrete compatibility evidence. I would emit warnings first, then move to hard errors in a later release.

[rami3l]

@ychampion Thanks for the investigation! In that case I suggest leaving this PR as-is or convert it to draft, and instead use another PR to issue a warning first (that should also allow closing the original issue as resolved).