Reusable-workflow wrappers startup-fail estate-wide: callers grant narrower permissions than the reusable's jobs request

[hyperpolymath]

Root cause (diagnosed + fixed in ochrance, PRs hyperpolymath/ochrance#73–#75)

A called reusable workflow can only narrow the caller's GITHUB_TOKEN — if any of its jobs request a permission the caller didn't grant, the run dies at load time as startup_failure ("This run likely failed because of a workflow file issue", zero jobs). Two current instances:

1. secret-scanner-reusable.yml: the gitleaks job requests pull-requests: write + actions: read, but the documented caller example (and the deployed wrappers) grant only contents: read. Every wrapper deployed from that example startup-fails — in ochrance, since the 2026-06-24 repin, i.e. the secret scanner has not scanned anything for a week while looking like mere CI noise. The comment in the reusable claiming job-level permission blocks "OVERRIDE the caller's" states the semantics backwards.
2. scorecard-reusable.yml: the scorecard job requests security-events: write + id-token: write; wrappers granting permissions: read-all startup-fail the same way.

This is very likely the estate-wide "C3 startup_failure class" observed on 2026-07-01.

Fix (per ochrance)

Caller grants the superset:

• secret-scanner wrapper: contents: read + pull-requests: write + actions: read
• scorecard wrapper: contents: read + actions: read + security-events: write + id-token: write

Verified green on ochrance main after the change.

Asks

• Fix the caller example in secret-scanner-reusable.yml's header comment + correct the inverted "override" comment
• Fix the wrapper templates (rsr-template-repo follows standards here)
• Estate sweep: any repo whose secret-scanner.yml/scorecard.yml wrapper has the narrow grant is silently unscanned

🤖 Generated with Claude Code