feat: improve release process with signing, install scripts, and build fixes

[jacderida]

Summary

• Add ML-DSA-65 (FIPS 204) post-quantum signing for all release archives via ant-keygen, with SHA256 checksums
• Add Windows install script (install.ps1) using irm | iex pattern, matching the existing install.sh for Linux/macOS
• Fix musl Linux builds (vendored OpenSSL for unix, cross for aarch64-musl)
• Fix Windows build (shell: bash for conditional build step)
• Skip cargo publish for RC versions (-rc. tag guard)
• Update release body with install scripts, verification instructions, and DigiCert EV code-signing note
• Replace winget manifest validation with install.ps1 test in install-test workflow
• Update bootstrap peers with current production IPs
• Update README installation section
• Add resources/release-signing-key.pub for signature verification

Test plan

• Full end-to-end release tested with ant-cli-v0.1.2-rc.1 tag
• All 5 build targets pass (x86_64/aarch64 linux-musl, x86_64/aarch64 macOS, x86_64 Windows)
• Windows DigiCert code signing works
• ML-DSA-65 signatures generated and verified with public key
• RC version correctly skips crate publishing
• RC version marked as prerelease on GitHub
• Install scripts tested on all 3 platforms (Linux, macOS, Windows)
• SHA256SUMS.txt and .sig files attached to release
• Clean up test RC release and tag after merge

🤖 Generated with Claude Code

[Nic-dorman]

Overall: Solid release engineering work. The move to cross for aarch64-musl, ML-DSA-65 signing, and the Windows install script are all good additions. A few items worth addressing:

Issues:

1. Signing key not securely cleaned (ant-cli-release.yml:253) — The clean up signing key step uses rm -f, but for sensitive key material, consider shred -u or at minimum zero-fill before delete. rm just
   unlinks the inode; the bytes remain on disk. On ephemeral CI runners this is low-risk, but it's a good habit.
2. install.ps1 assumes x86_64 only (line 48) — $Target is hardcoded to x86_64-pc-windows-msvc. ARM64 Windows (Surface Pro X, etc.) users will silently get an x86 binary running under emulation. Consider
   detecting $env:PROCESSOR_ARCHITECTURE and either picking the right target or warning the user.
3. install.ps1 — no signature verification — The Linux install.sh presumably doesn't verify either, but since this PR adds ML-DSA-65 signing infrastructure, it would be good to at least mention how to verify
   in the script's header comment, or add an optional verification step. Not blocking, but a follow-up opportunity.
4. install.ps1 — PATH modification without confirmation (line 78-82) — Silently modifying the user's PATH environment variable is aggressive. Most install scripts at least print a message before doing this, or
   ask for consent. The script does print after, but not before. Minor, but some users won't expect irm | iex to touch their permanent PATH.
5. Vendored OpenSSL only for unix (ant-core/Cargo.toml) — The openssl = { version = "0.10", features = ["vendored"] } dependency is added under [target.'cfg(unix)'.dependencies]. This is fine for the musl
   build fix, but is ant-core actually using OpenSSL directly, or is this just to ensure openssl-sys links statically for transitive deps? If the latter, a comment explaining the "why" would help future
   maintainers.
6. sha256sum with || true (release workflow line ~267) — The sha256sum ant-* 2>/dev/null > SHA256SUMS.txt || true silently swallows failures. If no archives exist (a build failure upstream), the release step
   will happily publish an empty SHA256SUMS.txt. Consider failing if no files match.
7. publish-crate job is now disconnected — With the if: ${{ !contains(github.ref_name, '-rc.') }} guard added, the release job no longer has publish-crate in its needs. This means release can run concurrently
   with publish-crate for non-RC releases. Is that intentional? If publish-crate fails, you'd still have a GitHub release published.

Nits:

• The release body heredoc has install instructions pointing at raw.githubusercontent.com/...main/install.ps1. After merge this works, but if someone forks or the default branch changes, these URLs break. A
  minor concern.
• bootstrap_peers.toml IP changes — presumably these are just new production nodes, no review needed on the values themselves.

Looks good overall. The CI/CD changes are well-structured with the new sign-releases job consolidating artifact handling.