Adopt standard Rust release-asset naming and add SHA-256 checksums

[whme]

Background

csshw currently publishes a single release asset per version: csshw.<version>.zip, containing csshw.exe, README, and LICENSE.

A survey of comparable Rust CLI projects on GitHub (ripgrep, fd, bat, hyperfine, just, zoxide, starship, sccache) shows that the ecosystem has converged on a different convention:

• Asset naming: <name>-v<version>-<rust-target-triple>.zip
• Checksums: a sibling .sha256 file per archive
• Architectures: both x86_64-pc-windows-msvc and aarch64-pc-windows-msvc

Adopting this convention has concrete downstream benefits:

• Makes winget and scoop autoupdaters work out-of-the-box against our release feed.
• Matches what users coming from neighbouring tools already expect.
• Adding ARM64 in the same release flow costs almost nothing once CI is plumbed.
• Per-asset .sha256 files are required by scoop manifests and expected by careful users.

The current csshw.0.19.1.zip filename is unusual (period-as-separator, no target triple) and would need to be special-cased in any third-party package manifest.

Proposed changes

Rename and extend the release artifacts produced by the release workflow:

csshw-v<version>-x86_64-pc-windows-msvc.zip          (csshw.exe + README + LICENSE)
csshw-v<version>-x86_64-pc-windows-msvc.zip.sha256
csshw-v<version>-aarch64-pc-windows-msvc.zip         (once CI builds it)
csshw-v<version>-aarch64-pc-windows-msvc.zip.sha256

Zip contents stay the same; only the filename changes, plus the new checksum sibling and the optional aarch64 build.

Explicit non-goals

The following were considered and intentionally deferred:

• Switching to a bare .exe asset. Loses LICENSE bundling (MIT obligation), triggers more browser/SmartScreen friction for downloaders, and would make csshw an outlier among peer Rust CLIs.
• Shipping an MSI installer. cargo-wix makes this cheap to add later; doing it speculatively adds maintenance without a clear user need. Revisit if enterprise GPO/SCCM deployment becomes a real ask.
• Code signing. Since late 2024 Microsoft treats EV and standard certs equivalently for SmartScreen reputation - signing buys a publisher name in the prompt but not warning-free first-run. The existing SmartScreen-warning docs (157d9b8) are the right interim solution. Revisit when download volume makes organic reputation accrual worthwhile.
• winget / scoop submission. Separate follow-up issue once the new asset naming is live - the manifest will use InstallerType: zip + NestedInstallerType: portable.

Acceptance criteria

• Release workflow produces csshw-v<version>-x86_64-pc-windows-msvc.zip instead of csshw.<version>.zip.
• Release workflow produces a <asset>.sha256 sibling per zip.
• (Optional, can be a follow-up) Release workflow also produces an aarch64-pc-windows-msvc zip + checksum.
• Zip contents (csshw.exe, README, LICENSE) unchanged.
• README installation instructions updated to reference the new filename.