fix(ci): grant the secret-scanner reusable its required job permissions

[hyperpolymath]

Every Secret Scanner run in this repo has been ending in startup_failure — meaning secret scanning has never actually executed here.

Root cause

A called reusable workflow may only request permissions equal to or more restrictive than its caller. This is enforced when the workflow file is parsed, before a runner is allocated — which is why it surfaces as startup_failure with no logs and no annotations.

secret-scanner-reusable.yml declares this on its gitleaks job:

permissions:
  contents: read
  pull-requests: write   # gitleaks-action posts the PR summary comment
  actions: read          # workflow-run metadata / PR-files endpoint

This caller granted only the file-level permissions: contents: read, so the reusable was asking for more than the caller had. GitHub refused the run outright.

Evidence

Two repos pinning the identical reusable SHA behave differently based only on this block: modshells (grants the superset) runs fine; verisimdb (does not) startup_failures. Estate-wide, 176 callers grant it and run; 26 do not and are all dead.

Fix

Grant the superset at job level — byte-identical to the canonical template. No SHA pin is changed, so the scanned content and supply-chain posture are unaffected; this only lets the existing pinned scanner start.

Verification

After merge, Secret Scanner should move from startup_failure to an actual run with gitleaks / rust-secrets / shell-secrets jobs.

🤖 Generated with Claude Code

[hyperpolymath]

Superseded by #72 — this branch's commit was created via the Contents API and is unsigned, which the repo's required_signatures rule rejects (mergeStateStatus: BLOCKED). The replacement carries a verified signature.