Summary

Supply-chain hardening follow-up (flagged in the #3634 review). Every scripts/setup/* script downloads a build dependency over HTTPS and builds/bundles it into release artifacts without verifying the download's integrity — no SHA256 pin, no signature check. A compromised upstream/CDN, a hijacked release asset, or a TLS-MITM could substitute a malicious artifact that lands in shipped binaries, and nothing would catch it.

This is consistent across the board (not a regression from any one PR), so it's worth fixing as one sweep.

Affected scripts / downloads

(Confirmed: grep -rinE "sha256|Get-FileHash|checksum" scripts/setup/ → zero hits today.)

Proposed fix

For each download, pin the expected SHA256 next to the URL/version and verify after download, before extract/build, failing hard on mismatch:

• PowerShell: (Get-FileHash $file -Algorithm SHA256).Hash -eq $Expected → else Write-Error; exit 1.
• Bash: echo "$EXPECTED $file" | sha256sum -c - (or shasum -a 256 on macOS).

Notes:

• The version string is already part of each cache key, so a version bump naturally requires bumping the pinned hash too — keep them adjacent so they move together.
• For the two-mirror case (setup-opus.ps1), the same hash verifies whichever mirror served the file.
• Optional stretch: a tiny shared helper (Verify-Sha256) so the six scripts don't each hand-roll it.

Acceptance

• Every external download in scripts/setup/ verifies a pinned SHA256 and aborts on mismatch.
• A deliberately-wrong hash fails the setup step (quick local check).

Refs #3634, #3600.