fix(secret-scan): inherit caller permissions to avoid startup failure [DEV-404]

[brodkin]

Why

Follow-up to #46. The reusable secret-scan workflow declared security-events: write at the top level. A reusable workflow that requests a permission scope the caller didn't grant fails at startup — zero jobs, before any step runs. Every existing caller grants only contents: read + pull-requests: write, so the new v1 produced a startup_failure for them, including KG-Power-BI PR #1. The continue-on-error guard on the SARIF upload can't help because the run never starts.

(Confirmed live: KG-Power-BI PR #1's reopen-triggered run 27051004405 → startup_failure, zero jobs.)

Fix

Remove the top-level permissions: block so the reusable workflow inherits the calling job's permissions:

• contents: read — every caller grants it (checkout).
• security-events: write — optional; only callers that grant it (the example does) get the SARIF upload to the Security tab on public repos. Others scan, fail the check, and the upload no-ops.

Compatibility

Backward compatible with all existing callers — no caller changes required. Opted-in callers (granting security-events: write) still get SARIF on public repos.

Validation

• actionlint clean.
• Root cause matches the only permissions-relevant delta vs. the old workflow (old declared pull-requests: write, which matched callers; new declared security-events: write, which they lack).

Part of [DEV-404]. Unblocks [DEV-401].

[pepper-pr-review]

Girl, this is the fix. The old v1 declared security-events: write at the top level, but callers that only granted contents: read hit a startup failure before any job ran — exactly the KG-Power-BI situation you cited. Removing the permissions: block so the workflow inherits from the caller is the right move: every caller grants contents: read (checkout needs it), and security-events: write becomes opt-in for the SARIF upload, which already has continue-on-error as the safety net.

Verified against DEV-404 (Linear) — aligned. The example caller already grants both permissions, so backward compatible. The new comment block at lines 66–75 teaches the pattern clearly. Clean.

— Pepper

When you're ready for another look, drop @pepper review in the comments.