ci: a fork can pass the release check, and absent provenance cannot

[The01Geek]

A judge change, so it lands as its own policy-update/* pull request carrying only .github/workflows/distribution-verify.yml — evaluated by the base branch's verifier.

1. A fork could never pass the required check

The exemption that skips artifact verification for an ordinary pull request was gated on the pull request coming from this repository. A fork matched no arm, fell through to full verification, and failed on every file it changed — so every outside contribution showed a permanently red required check it could do nothing about.

That gate was collateral from the v2.38.1 fork-bypass fix. The hole that fix closed is in the judge-comparison step above, which this change does not touch: its exemptions remain gated on same-repository origin, so a fork still cannot introduce or edit the verifier that judges it.

Skipping grants a fork exactly what a same-repository pull request already gets. It also reduces candidate code execution — a fork no longer reaches the verifier invocation at all.

2. A tree carrying no provenance reported success

case "$HEAD_REF" in
  release/*) exit 1 ;;
  *)         exit 0 ;;   # a push carries "main"
esac

The guard refusing an absent .release/source.json keyed on the branch name alone. A push carries main, not a release/* name, so deleting that one file turned the whole check green on the published branch. A pull request that deletes provenance the base carries is now refused too.

Verification

The step's real run block was extracted from the YAML and executed across the matrix:

case	before	after
push to main, no provenance	green	fails
pull request deletes provenance	green	fails
release/*, no provenance	fails	fails
ordinary pull request, any origin	fork red	skips
release/* pull request, any origin	verified	verified
push to main, provenance present	verified	verified
tree that never carried provenance	passes	passes

That last row is the pre-first-release bootstrap the guard promises, and it is preserved.

Expected consequence

This edits a file .release/files.sha256 covers without regenerating it, so main will fail its own check from this merge until the next release republishes .release/. That is the known, self-healing policy-update window, and the release follows immediately.