Track upstream verification/provenance requests blocking allowlist bumps

[potiuk]

Several allowlist bumps are blocked on upstream actions adding verification or
provenance for artifacts they ship or download. Filing these individually works

• upstream has acted on them before - but there is nowhere to see which are
  outstanding and what each one blocks.

Open

Upstream issue	Ask	Blocks
ReactiveCircus/android-emulator-runner#485	Verify the Android cmdline-tools zip after tc.downloadTool. No checksum today, and the _latest URL is republishable	#1100 - its last remaining finding
1Password/load-secrets-action#186	Add actions/attest-build-provenance or a SHA256SUMS release asset covering dist/core_bg.wasm, new in v5.0.0 and unattested	#1141
1Password/load-secrets-action#168	Verify the op CLI download before extracting. Open since 2026-06-13, no response	carried over on every load-secrets-action bump

Resolved, as precedent that the ask lands

• Add build provenance attestations + signed release artifacts so downstream consumers can verify binaries runs-on/action#36 -> Dubious re-use of class as boolean variable #37: maintainer added actions/attest-build-provenance
  and started shipping SHA256SUMS; later bumps verify automatically.
• Optional: verify the mise download's minisign signature against a pinned key by default jdx/mise-action#547 -> Removed trivy from actions.yml #548: fixed same-day with signed-checksum
  verification.

How these should affect review

Pinning an action with a known finding is still strictly better than the
wildcard it replaces, so an open upstream request should not usually block a
bump on its own. The exception is a newly introduced opaque binary - the #1141
case - where no previously approved version carries the same exposure, so
accepting it would be a genuine regression rather than a carried-over warning.

---

Drafted-by: Claude Opus 5 (1M context) via Claude Code; reviewed by @potiuk before posting