ci: pin and verify MCP publisher artifact

[ronheichman]

Why

The MCP registry publish workflow downloads and executes the moving upstream latest publisher artifact in the same job that receives MCP_REGISTRY_PRIVATE_KEY. Production environment approval limits when the job runs, but it does not verify which publisher binary receives that key. This creates a concrete registry-publication and credential-exposure path if the upstream publisher release channel is compromised.

What changed

• Pin the publisher download to upstream release v1.8.1 and its Linux amd64 asset.
• Verify the independently checked SHA-256 before extracting or executing the publisher.
• Fail downloads explicitly while preserving the existing production environment gate.

This is intentionally scoped to MCP registry publication. The separate npm OIDC/provenance workflow and other CLI release chains are unchanged.

Verification evidence

The pinned digest a06c9096dcb9727c13555b6be26c7effa707b01f06a4c561ba7a3635443cf2cc agrees across the upstream checksum file, GitHub's release-asset digest, and an independently downloaded v1.8.1 archive. The verification command accepts that archive and rejects a mismatched digest before extraction.

Review

MCP release owners: @rbuchmayer-pplx and @kesku.

[ronheichman]

@rbuchmayer-pplx @kesku Please review this bounded Code Red #57 hardening change. The forked PR test run is currently awaiting maintainer authorization; local build and all 90 repository tests pass, and the pinned publisher archive accepts the verified digest and deterministically rejects a mismatch.