accelerate CI via cargo binstall

[plebhash]

accelerate CI via cargo-binstall

instead of compiling cargo-nextest, cargo-semver-checks, and cargo-fuzz on every run, we install pre-built binaries via cargo-binstall.

additional hardening:

• disable quick-install option to only use upstream release artifacts (instead of third-party quick-install artifacts)
• pass GITHUB_TOKEN to cargo-binstall to avoid unauthenticated GitHub API rate-limit fallback
• use --locked for deterministic fallback behavior if source install is ever needed
• run fuzz with an explicit rustc host target to avoid sanitizer/libc mismatches

estimated impact (latest successful PR run vs median of 5 recent comparable successful PR runs on the same workflows/jobs):

• ci (ubuntu-latest):
  • tool install: ~2m33s -> ~2s (~99% reduction)
  • total job: ~31m27s -> ~29m05s (~2m22s faster, ~8%)
• ci (macos-latest):
  • tool install: ~2m18s -> ~4s (~97% reduction)
  • total job: ~30m16s -> ~29m01s (~1m15s faster, ~4%)
• semver-check:
  • tool install: ~3m53s -> ~2s (~99% reduction)
  • total job: ~7m12s -> ~3m17s (~3m55s faster, ~54%)
• fuzz:
  • tool install: ~20s -> ~2s (~90% reduction)
  • total job: ~1m14s -> ~1m01s (~13s faster, ~18%)

critical-path wall clock improves (~31m27s -> ~29m05s, ~2m22s), while matrix jobs still run in parallel.

[GitGab19]

One nit found by my clanker, which pins the version for real.

Without it, the action still downloads the latest it seems: https://github.com/stratum-mining/stratum/actions/runs/27847218527/job/82418833360?pr=2209#step:5:35

[Shourya742]

Is this version beside binstall required anymore, considering now we have with version attribute? I think we can remove it