…n template

`.azure-pipelines/templates/Rust.Toolchain.Public.yml` is the public-
bootstrap rustup install used by lint, fork-PR builds, and the macOS
build. It previously fetched `rustup-init` from the convenience
redirectors `https://win.rustup.rs/x86_64` and `https://sh.rustup.rs`
and executed it **without any integrity check** on every trusted run.

## Threat

Those URLs are convenience redirectors that always return the latest
rustup release. A compromise of the redirect, the rustup origin, or
the TLS chain would silently propagate into every trusted build that
uses this template. The lint job in particular also rewires crates.io
to an anonymous public mirror via
`.azure-pipelines/.cargo/config.public.toml`, so a compromised
`rustup-init` could expand the blast radius into any compiled
artifact the lint job touches.

## Fix

This template now:

1. **Pins the rustup version** via a new `rustupInitVersion` parameter
   (default `1.28.2`) and fetches from the immutable archive URL
   `static.rust-lang.org/rustup/archive/<ver>/<host-triple>/`. That
   URL is byte-stable for a given (version, triple); the previous
   `latest` URL would defeat any pinned SHA the first time rust-lang
   shipped a new release, which is what made hash pinning impossible
   under the old layout.

2. **Selects the host triple from the actual agent**, not from the
   build target. Windows agents are always x64 (windows/arm64 builds
   run on x64 agents and cross-compile via `--target`), so the
   Windows download is hardcoded to `x86_64-pc-windows-msvc`. On
   Linux / macOS the host arch is read from `uname -m` and
   translated to a Rust triple via an explicit per-OS switch; unknown
   architectures throw with a clear message rather than silently
   downloading an unrunnable binary. The TARGET toolchain is still
   installed via `rustup-init --target \`. The resolved
   host / target triples are logged to the job output so any future
   cross-compile mismatch is one `grep` away.

3. **Verifies the SHA-256 sidecar** from the same origin against the
   downloaded `rustup-init` BEFORE executing. This matches what
   `rustup` itself does for self-update. On mismatch the job fails
   loudly with both expected and actual hashes so an operator can
   audit.

4. **Documents the residual threat clearly:** SHA-256 sidecar
   verification defends against integrity-of-payload (in-flight
   corruption, TLS MITM, truncation) but **not** against
   authenticity-of-origin (a compromise of `static.rust-lang.org`
   itself would corrupt both the binary and the sidecar). Defending
   against the latter requires upstream GPG release-key verification
   and is out of scope here.

## Trade-off considered and rejected

Switching the lint job to `RustInstaller@1` + `CargoAuthenticate`
(matching `Rust.Build.Steps.Official.yml`) would have removed the
public bootstrap entirely BUT also broken fork-PR linting -- external
contributors have no `System.AccessToken` for the internal
`Mxc-Azure-Feed`. The integrity-verification approach preserves
fork-PR linting while still meaningfully hardening trusted runs.

## Compatibility

The two existing call sites
(`.azure-pipelines/jobs/Lint.Job.yml` and
`.azure-pipelines/templates/Rust.Build.Steps.Unofficial.yml`) are
unchanged: the new `rustupInitVersion` parameter has a default, so
backward compatibility is automatic. Bumping the pin in future is a
single-line change in this file.

## Verification

  YAML parses (PyYAML): 3 parameters, 1 step                OK
  No call-site changes needed (default-valued parameter)    OK
  No Rust code touched -> no cargo build/clippy/test rerun  N/A
  CI rerun deferred to actual pipeline execution on this PR
    (the lint job exercises the changed template directly).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>