feat(npm): verify SHA-256 of downloaded binary against checksums.txt

[btwshivam]

npm/postinstall.js downloads the release tarball from GitHub Releases but never validates its digest:

$ grep -in 'checksum\|sha256\|hash' npm/postinstall.js
74:    console.log('optiqor: ready. Run `optiqor --version` to verify.');

only match is a log line. goreleaser already produces checksums.txt in every release. nothing in the install path uses it.

result: anyone who can intercept the download (mitm, hijacked release asset, compromised mirror) ships arbitrary binaries to every npm install -g @optiqor/cli user. this is the exact supply-chain risk the README pitches against ("All release artifacts are signed with Cosign").

scope:

1. fetch checksums.txt from the same release tag
2. hash the downloaded tarball: crypto.createHash('sha256').update(buf).digest('hex')
3. compare against the entry in checksums.txt matching the archive filename
4. on mismatch, delete the tarball and fail loud (process.exit(1))

bonus: cosign-verify checksums.txt itself. cosign is already in the goreleaser pipeline, so the public key + signature exist in the release. that closes the loop the README claims.

[saurabhhhcodes]

/assign

I would like to work on this.

Plan: fetch the release checksums.txt alongside the npm binary archive, parse the checksum line for the exact archive filename, compute the downloaded tarball SHA-256 with Node crypto, fail loudly and delete the tarball on mismatch or missing checksum, and add focused tests around checksum parsing/verification plus the failure path. I will keep the first PR scoped to SHA-256 verification and avoid private key/cosign material unless maintainers want that as a follow-up.

[github-actions]

Assigned to @saurabhhhcodes. Thanks for picking this up!

Heads-up: if there's no activity (comment or PR linked here) within 10 days, the issue will be auto-released so others can pick it up. Comment any time to reset that timer.

Need help getting started? Check CONTRIBUTING.md or ask in the issue thread.