binpm: diagnose Sigstore identity mismatches #633

Summary

For packages installed by binpm, Sigstore verification only satisfies strict verification when the bundle validates with the expected issuer and a certificate identity matching the source repository workflow at the release tag. A valid-looking Sigstore bundle can still fail this policy.

Evidence

• docs/crates-binpm-foundation.md says supported package signature verification uses GitHub.com release asset Sigstore bundle sidecars named <selected-asset>.sigstore.json.
• Verification must use issuer https://token.actions.githubusercontent.com and a certificate identity matching https://github.com/<owner>/<repo>/.github/workflows/<workflow>@refs/tags/<release-tag>.
• Package signature verification is distinct from direct-installer verification for binpm's own release artifacts.

Current Gap

Users may only see that a Sigstore bundle exists, then be surprised by strict verification failure when issuer, identity, repository, workflow, or tag reference does not match the policy.

Proposed Scope

Add verification diagnostics that report which trust-policy predicate failed without leaking sensitive data, and document common upstream fixes.

Acceptance Criteria

• Failed Sigstore verification distinguishes bundle parse failure, issuer mismatch, identity mismatch, asset mismatch, and tag mismatch where possible.
• Human output explains the expected identity pattern for the selected source.
• JSON diagnostics expose stable verification failure reasons.
• Docs include maintainer guidance for producing compatible bundles.

Test Scenarios

• Bundle issuer is not GitHub Actions OIDC.
• Bundle identity points to a branch ref instead of refs/tags/<release-tag>.
• Bundle identity points to a different repository.
• Matching bundle verifies successfully.

Out of Scope

• Trusting arbitrary Sigstore identities without a documented policy.
• Changing direct-installer verification semantics.