Record the certificate's source ref and runner environment in lock provenance

[samuv]

Summary

The provenance we pin identifies a repository and a workflow file, but not the git ref. A signature produced by that same workflow on any branch of that repository satisfies the policy.

Surfaced while explaining the trust model; never in scope for v1.

What is recorded today

provenance:
  signerIdentity: /.github/workflows/build-skills.yml
  certIssuer: https://token.actions.githubusercontent.com
  repositoryUri: https://github.com/stacklok/dockyard
  sigstoreUrl: https://rekor.sigstore.dev

signerIdentity is the SAN with the repository URI trimmed off the front and the ref cut from the end. toolhive-core's signerIdentityFromCertificate does:

builderURL, _, _ = strings.Cut(builderURL, "@")            // drops @refs/heads/main
builderURL = strings.TrimPrefix(builderURL, c.SourceRepositoryURI)

and the verification policy reassembles them with a trailing (@.*)?$, which is what makes any ref match.

What the certificate actually carries

A real Fulcio cert from ghcr.io/stacklok/dockyard/skills/tdd:0.1.0:

OID	Value
.1.5 repository	stacklok/dockyard
.1.6 ref	refs/heads/main
.1.3 commit	29c7bc58fa8d1042ff73a9154e120c022cf908df
.1.11 runner	github-hosted
.1.21 run URL	.../actions/runs/25171716698/attempts/1
.1.22 visibility	public

So the information exists and is simply discarded.

Why it matters

The guarantee reduces to "someone who can make that workflow path run in that repository". Branch protection on main does not help if a signature from any branch is accepted. Recording .1.6 and .1.11 would tighten it to "on this ref, on a hosted runner".

toolhive-core already knows how to compare both — compareBaseProperties checks RepositoryRef and RunnerEnvironment for MCP server provenance. The skills lock just never records them.

Scope and the compatibility question

• Add the fields to lockfile.Provenance and populate them from the verification result.
• Bind them into the verification policy where core supports it.
• Existing lock files have neither field. Enforcing them against entries written before this change would break every project on upgrade. Decide deliberately: absent means unconstrained (backward compatible, weaker), or absent triggers a re-pin. This is the crux of the issue, not an implementation detail.

Related: #6307 (keyless signing produces these certs).

[samuv]

Shipped in full:

• B1 Record certificate ref and runner in lock provenance #6312: added RepositoryRef and RunnerEnvironment to lockfile.Provenance and threaded them through the API/CLI DTOs.
• B2 Enforce recorded ref and runner on skill verification #6315: extraction from the verified certificate and post-hoc enforcement in the verifier, plus ErrProvenanceFieldMismatch / FailureReasonProvenanceFieldMismatch so a ref/runner mismatch classifies distinctly from a signer-identity mismatch.

Decision on the compatibility question this issue raised (absent-field handling): absent means unconstrained, matching the existing RepositoryURI precedent — old lock files load unchanged and are not retroactively tightened. Enforcement is exact-match on install/sync; any ref or runner-class change (tag, branch, git, or OCI) blocks like a signer-identity change and needs --allow-signer-change — no automatic re-pin allowance, after panel review on #6315 found that a naive "tag→tag auto-allowed" rule would let a candidate signed from an attacker's own tag on the same repo replace a pinned tag.

Closing as done.