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

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:

```yaml
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, and 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_failure`s. Estate-wide, 176 callers
grant it and run; 26 did not and were 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.

### Verified

On `hyperpolymath/vext`, this exact change moved `Secret Scanner` from
`startup_failure` to **success**, with `gitleaks`, `rust-secrets` and
`shell-secrets` all allocating runners and passing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: hyperpolymath