ci: stop pinning an unused rust toolchain in the snap build

[prql-bot]

The snap build's rust-deps part pins --default-toolchain 1.75.0, which has no effect: the prqlc part builds from the source tree, so rustup resolves the toolchain from rust-toolchain.toml (currently 1.97.1) instead. The pin only costs an extra toolchain download, and it reads as an MSRV guarantee the build never makes — the workspace MSRV moved to 1.81.0 in b11de3d and nothing here noticed. MSRV is actually enforced by test-msrv in tests.yaml, which runs cargo msrv verify against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml; with this change 1.75.0 appears nowhere in the repo.

Evidence from the last release (run 30102103832, build-and-publish-snap, 0.13.14):

:: info: default toolchain set to 1.75.0-x86_64-unknown-linux-gnu
:: info: syncing channel updates for 1.96.1-x86_64-unknown-linux-gnu
:: warning: default toolchain implicitly overridden with `1.96.1-x86_64-unknown-linux-gnu` by rustup toolchain file

1.75.0 is installed and then never used; the build compiles under the toolchain file's channel. This switches the pin to none so rustup installs only the toolchain the build actually resolves, and records why in a comment so the next MSRV bump doesn't re-add a pin here.

This supersedes the intent of #5771, which bumped the pin to track MSRV — the pin it was maintaining was already inert.

No test: the snap build runs only from release.yaml on a tag, so it can't be exercised from a PR. I verified the YAML still parses and that the folded scalar joins to the intended single command line. The risk specific to none is that no default toolchain exists at all, so a cargo/rustc call made with a cwd outside the copied source tree would fail with no default toolchain configured — but the same job log shows the current parts graph issues exactly two cargo invocations, both from inside the tree and both resolving through rust-toolchain.toml, so nothing today needs a default. What remains unverified is a future part or plugin step that invokes cargo from elsewhere.

The two cargo invocations, from run 30102103832

14:49:39 :: info: default toolchain set to 1.75.0-x86_64-unknown-linux-gnu
14:49:39 User does not want to use rustup, skipping
14:49:40 :: + cargo read-manifest --manifest-path prqlc/prqlc/Cargo.toml
14:49:40 :: info: syncing channel updates for 1.96.1-x86_64-unknown-linux-gnu
14:49:50 :: + cargo install -f --locked --path prqlc/prqlc --root /root/parts/prqlc/install
14:49:50 :: warning: default toolchain implicitly overridden with `1.96.1-x86_64-unknown-linux-gnu` by rustup toolchain file

Both paths are relative (--manifest-path prqlc/prqlc/Cargo.toml, --path prqlc/prqlc), which places the cwd at the root of the copied source tree — the directory holding rust-toolchain.toml. Each invocation syncs 1.96.1 rather than the 1.75.0 default, confirming the toolchain file wins. The rust plugin's own pull-step line (User does not want to use rustup, skipping) triggers no channel sync, so it resolves /usr/bin/cargo from build-packages: [cargo], which the rustup default doesn't affect either way.

[prql-bot]

One suggestion on the new comment: its first line says "No --default-toolchain", but the code passes --default-toolchain none. Those aren't the same — omitting the flag makes rustup-init install stable, which reinstalls exactly the extra unused toolchain this PR is removing. Someone tidying up against the comment later would undo the change.

On the PR body's "unverified against a real snap build" caveat — I dug into the 0.13.14 job log and it narrows that risk more than the description claims. The concern with none is that no default toolchain exists at all, so any cargo/rustc call with a cwd outside the copied source tree would fail with no default toolchain configured. In that run every invocation is inside it, so nothing in the current parts graph needs a default. The residual risk is a future part or plugin step that invokes cargo from elsewhere.

Not approving because I'm the author, not because of the finding above.

Evidence from run 30102103832 (build-and-publish-snap, 0.13.14)

The whole build issues three cargo invocations, all resolved through the rustup shim with cwd = /root/parts/prqlc/build, which holds the copied tree including rust-toolchain.toml:

14:49:40 Generating build commands for prqlc/prqlc
14:49:40 :: + cargo read-manifest --manifest-path prqlc/prqlc/Cargo.toml
14:49:40 :: info: syncing channel updates for 1.96.1-x86_64-unknown-linux-gnu
14:49:50 :: + cargo install -f --locked --path prqlc/prqlc --root /root/parts/prqlc/install
14:49:50 :: warning: default toolchain implicitly overridden with `1.96.1-x86_64-unknown-linux-gnu` by rustup toolchain file
14:52:13 :: + rm -f /root/parts/prqlc/install/.crates.toml ...

The relative --manifest-path confirms the cwd. The rust plugin's own pull-step check (User does not want to use rustup, skipping, 14:49:39.35) triggers no toolchain sync, so it isn't going through the shim — it resolves /usr/bin/cargo from build-packages: [cargo], which is unaffected by the rustup default.

MSRV coverage isn't lost with the pin gone: test-msrv in tests.yaml runs cargo msrv verify against metadata.msrv = "1.81.0" in prqlc/prqlc/Cargo.toml. 1.75.0 appears nowhere else in the repo.

yaml.safe_load on the changed file folds override-pull to the intended single line: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --profile minimal --default-toolchain none.