[codex] Harden GitHub Actions

[intertwine]

What changed

• pin third-party GitHub Actions to immutable commit SHAs
• add .github/CODEOWNERS coverage for workflow and action changes
• add a dependency-review workflow for dependency and workflow diffs
• set top-level workflow permissions to contents: read where the existing jobs did not need broader default access

Why

This reduces exposure to supply-chain style compromises that rely on mutable action tags, unreviewed workflow changes, or surprising dependency changes in pull requests.

Validation

• loaded all workflow YAML files successfully
• verified there are no remaining mutable uses: refs in the touched workflow set
• confirmed 12 full-SHA action pins are present under .github/workflows

[intertwine]

@claude review

[claude]

Claude finished @intertwine's task in 2m 24s —— View job

---

Code Review

• Gather context
• Read changed files
• Analyze changes
• Post review

---

Overall this is a clean, well-scoped hardening PR. All third-party actions are correctly pinned to immutable SHAs with version comments, top-level permissions: contents: read is applied consistently, and the new workflows follow the same conventions. A few things worth addressing:

---

.github/CODEOWNERS — CODEOWNERS doesn't protect itself

The file covers .github/workflows/** and .github/actions/**, but not .github/CODEOWNERS itself. An actor with write access (or a compromised bot account) could push a commit that modifies CODEOWNERS to remove @intertwine as owner — and that commit would not trigger a required review because the file it modifies isn't yet protected.

Fix: add an explicit rule for the file itself (or the whole .github/ directory):

.github/CODEOWNERS @intertwine
.github/workflows/** @intertwine
.github/actions/**  @intertwine

Fix this →

---

.github/workflows/dependency-review.yml — paths filter includes workflow files (good), but worth a comment

Triggering on .github/workflows/** is intentional here — GitHub's dependency graph tracks Actions as a dependency ecosystem, so the action will flag newly added action pins with known CVEs. This is correct and useful. However, it's non-obvious; a brief inline comment would prevent a future reader from "simplifying" it away:

paths:
  - "pyproject.toml"
  - "uv.lock"
  - "poetry.lock"
  - "requirements*.txt"
  - ".github/workflows/**"  # GitHub tracks Actions in the dependency graph

---

.github/workflows/claude-code-review.yml — missing top-level permissions (minor inconsistency)

Every other workflow modified in this PR received permissions: contents: read at the top level. claude-code-review.yml only sets permissions at the job level (which is functionally equivalent, since job-level overrides the workflow default). No behavioral difference, but it's inconsistent with the pattern established here and leaves the workflow default wide-open until the job block is reached by the parser.

---

dependency-review.yml — no checkout step (correct, but worth noting)

The actions/dependency-review-action@v4 uses the GitHub Dependency Graph API and does not need a local checkout. The absence of a checkout step is intentional and correct. Worth knowing if anyone reads this later and wonders if it's missing.

---

SHA version comments — correct

The pre-existing code already used @v6 / @v8.0.0 tags, so the # v6 and # v8.0.0 comments in the pinned SHAs accurately reflect the source tags. No issue here.

---

Summary: One substantive gap (CODEOWNERS self-protection), one cosmetic inconsistency (top-level permissions in claude-code-review.yml), and one clarity suggestion (inline comment in dependency-review.yml). The SHA pinning, permission restrictions, and new workflows are all correct.