Verify the ToolHive CLI signature before executing it in CI #1115

.github/workflows/upstream-release-docs.yml runs scripts/install-thv.sh, which downloads the ToolHive CLI tarball from the releases/latest API response and executes it. That job holds contents: write and pull-requests: write and pushes commits to the PR branch, so a replaced release asset would run with those permissions.

The same script also runs in Vercel's buildCommand, so this isn't a new trust relationship for the repo, but the Actions job carries more consequence than the Vercel build does.

What would actually help

toolhive publishes a *.sigstore.json bundle per artifact (alongside toolhive_<version>_checksums.txt and SBOMs). Verifying the bundle with cosign against an expected identity would detect a replaced asset.

A checksum check is not a substitute: the checksums file comes from the same API response as the tarball URL, so anyone able to replace one can replace the other. It only guards a download that is already HTTPS.

Notes for whoever picks this up

• Don't pin the CLI to the release being documented. This workflow also runs for toolhive-studio and toolhive-registry-server, whose tags have no thv asset.
• Decide whether verification lands in install-thv.sh (covers Vercel and dev containers too, but adds a cosign dependency to the Vercel build) or in the Actions step alone.
• Needs an identity policy, not just cosign verify-blob: the certificate identity and OIDC issuer have to be asserted, or verification proves only that something signed it.

Raised by Copilot on #1114 (thread), deferred as its own change.