fix(ci): repin secret-scanner off orphan SHA

[arena-ai-coding-agent]

What

Follow-up to #95. Governance on main (f4e49a7) now passes Check SPDX headers + permissions ✅ but fails one step later:

::error::1 of 20 action pin(s) DO NOT EXIST upstream.
  NOT-ANCESTOR    hyperpolymath/standards@892497fe373744874316710966b81ae6f0ea9e66  (compare main → diverged)

Root cause (a real, determinate negative — not a flake): 892497fe, the pin on secret-scanner.yml's reusable workflow, is a real commit object but not an ancestor of standards/main (orphan — squash-merge residue / PR-head lineage). GitHub's resolver only accepts reusable-workflow commits reachable from the default branch, so:

• every Secret Scanner run (push and PR) fails at graph resolution with 0 jobs — the "This run likely failed because of a workflow file issue" rows red on main since at least fix(issues,setup): close #91 and #92; estate propagation runbook #93;
• the estate's updated pin gate (standards@main, now run by Governance's linter) determinately fails on it.

standards issue #782 documents this class: four such SHAs (7fdc2705…, 892497fe…, 46960521…, 5b1d0022…) account for 61 dead workflow-run rows with ZERO alive rows — aerie's secret-scanner pin is literally one of the named four.

Fix

Repin to e13e2ea3dbbc9c7815e39c3749b4480514f555a6 — the newest commit on standards/main touching the reusable (2026-09-19, standards #867):

• ancestry verified: compare/main...e13e2ea3 → behind (ancestor) — the same predicate the gate applies;
• strict superset of the orphan's content: estate gitleaks baseline wiring, full-history gating pass (fetch-depth: 0 + shallow-assert), --verbose findings, repo-local config resolution.

Per the gate's own guidance: repin to a merge commit on the default branch, never a PR head.

Verification (local, CI script versions)

Gate	Result
check-action-pins-resolve.sh (standards@main — what CI runs)	✅ 20/20
SPDX + permissions	✅
duplicate keys	✅ 17 clean
workflow parse	✅ 25

Expected effect after merge

• Governance → green (linter completes: SPDX ✓ → pin-resolve ✓ → dup-workflows ✓).
• Secret Scanner → schedules jobs for the first time (was unresolvable at graph resolution).

Note: Label Triage / Pages / Mirror / SonarQube remain owner-token items (allow-list, secrets) — see docs/REPO-SETTINGS.adoc §3/§9.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 8a11daab-bf68-4937-b8ba-0ff1552eb491

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[arena-ai-coding-agent]

Why the Actions checks aren't showing on this PR (diagnosis, not a PR defect)

All pull_request-event workflow runs since 2026-09-25 20:37Z complete as startup_failure with 0 jobs (this PR, #95, #94, and the concurrent 01a0da31 branch), while push runs in the same minutes schedule and run normally (0b8d9cb @20:39, cb2b475 @20:49, f4e49a7 @21:30 — Dogfood Gate green on f4e49a7 ✅).

Evidence that this is not a repo/allow-list problem

When	Event	Workflow files	Result
Sep 24 14:04 (aspect-weave)	pull_request	unchanged	jobs ran
Sep 25 14:25 (weave-p2)	pull_request	unchanged	jobs ran
Sep 25 20:37→	pull_request	unchanged	0-job startup_failure
Sep 25 20:39 / 20:49 / 21:30	push	same workflows	jobs ran

A refused uses: in the Actions allow-list would fail both events equally (the resolver is event-agnostic) — push works, so the allow-list is not refusing these actions. Same registered workflow IDs on dead and alive runs (256189032 for Dogfood), so this is not the synthetic/ghost-workflow routing either. Matches the September-2026 platform class of zero-job startup_failure runs (community discussions #207628, #206702, #207492, #207900; corroboration: Z-Solo-King/foundation#263).

What to do

• Don't read this PR's empty Actions check list as a repo failure — third-party checks (CodeFactor, CodeRabbit, GitGuardian, semgrep, Codeac) are green; mergeStateStatus: CLEAN.
• If PR checks are needed before merge: push an empty commit / close-reopen to re-trigger, or wait for platform recovery.
• Verification of this PR's content happens on the push to main after merge (push events currently schedule): expect Governance green (linter passes SPDX → pin-resolve 20/20 → dup-workflows) and Secret Scanner finally scheduling jobs (the orphan pin 892497fe was unreachable from standards/main — now repinned to ancestor e13e2ea3).
• docs/REPO-SETTINGS.adoc §9's allow-list reading should be re-verified with the owner token (bots get 403 on actions/permissions), but the current PR-event deaths don't match that signature.