Add cargo install fallback when prebuilt binary installer is unavailable

Summary

The generated release workflow installs cargo-dist itself via a prebuilt binary
installer (curl ... | sh). On architectures where no prebuilt binary is
published — such as riscv64 — this step fails and blocks the entire workflow.

I'd like to propose adding a cargo install cargo-dist --locked --version <version>
fallback so the workflow can proceed even when a prebuilt binary is not available
for the runner's architecture.

Background

The RISE Project recently announced the RISE RISC-V Runners (2026-03-24),
a free, managed GitHub Actions runner service backed by Scaleway bare-metal
RISC-V servers. Any open-source project can now run native RISC-V CI by setting
runs-on: ubuntu-24.04-riscv — no emulation, no cross-compilation, no waitlist.

This makes it practical for Rust projects to build and distribute riscv64
binaries through GitHub Actions. However, cargo-dist's own installer only ships
prebuilt binaries for x86_64 and aarch64, so the "Install dist" step in the
generated release.yml fails on RISC-V runners.

Proposed Change

In DistInstallStrategy::dash() / powershell(), append a fallback after the
installer command:

bash (sh):

curl --proto '=https' --tlsv1.2 -LsSf <url>/cargo-dist-installer.sh | sh \
  || cargo install cargo-dist --locked --version <version>

PowerShell:

try { irm <url>/cargo-dist-installer.ps1 | iex }
catch { cargo install cargo-dist --locked --version <version> }

This is safe because:

• GitHub Actions bash steps run with set -eo pipefail; -e does not trigger
  inside an || chain, and pipefail ensures curl failures propagate.
• On architectures where the prebuilt binary exists, the installer succeeds and
  the fallback never runs.
• cargo install --locked --version is deterministic and uses the published
  crate's lockfile.

The trade-off is that the fallback compiles from source, which is slower. This is
acceptable because the alternative is a hard failure with no workaround.

Start at DistInstallStrategy::dash() and powershell(), then inspect how the generated release.yml install commands are assembled. Verify the prebuilt installer failure paths on unsupported architectures and confirm that both shell and PowerShell workflows fall back to the specified cargo install command without changing the successful prebuilt path.