Source-sync workflow template: gate \translate-resync to trusted PR commenters and declare least-privilege permissions

[mmcky]

Copilot review of QuantEcon/lecture-python.myst#979 (the intermediate zh-cn sync wiring) found two hardening gaps in the source-sync workflow — and since #979 is byte-identical to the deployed template, both are fleet-wide. Same rollout pattern as #130 (same-repo head-branch guard): a Copilot catch on one PR that belongs in the template.

1. Unauthenticated \translate-resync. The template's job condition only checks contains(github.event.comment.body, '\translate-resync') on issue_comment: created. Any GitHub user commenting on any issue (not even a PR) fires a secrets-bearing run — Anthropic spend plus a PAT-authenticated job — at will. Fix applied on myst#979 (QuantEcon/lecture-python.myst@8abdb57): require github.event.issue.pull_request and contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association).

2. No permissions block. The action authenticates via its github-token input (the PAT), so the ambient GITHUB_TOKEN is unused beyond checkout — permissions: contents: read at job level is sufficient and shrinks the blast radius. Also applied in the same commit.

Scope: the canonical template in the docs (quickstart / connect-existing tutorial, source-sync side) plus the deployed instances — lecture-python-intro/sync-translations-zh-cn.yml, lecture-python-programming/sync-translations-{zh-cn,fa,fr}.yml, and any future edition wiring. myst#979 carries the fixed shape already; the others should adopt it once the template updates.

One design question worth settling while editing the template: whether author_association gating should also allow CONTRIBUTOR, given RA reviewers who may legitimately re-trigger syncs — the conservative OWNER/MEMBER/COLLABORATOR set is what shipped on myst#979.

[mmcky]

The 2026-07-23 technical-debt audit landed on the same file from a different direction, and the two changes should go in together — scheduled as #161 (Wave 1, PR D).

What the audit adds: five of the six in-repo review-workflow templates emit a target workflow that can never fire on the PRs it exists to review, and doctor passes the repo anyway. Only connect-existing.md is correct. Separately, translate setup scaffolds a workflow pinned to action v0.9.0 — 25 releases stale — with no permissions: and no concurrency: block.

Since a scaffolded workflow is a copy that never updates, the hardening described in this issue only reaches new repos unless it also lands in a canonical template that the generator and the doc pages all read from. That is the shape of the fix in #161, and it is why the permissions work and the can-never-fire bug are one PR rather than two.

[mmcky]

Closing as a duplicate of #192 — same fix, same template-first reasoning, different sighting (Copilot on QuantEcon/lecture-python.myst#979 here; QuantEcon/test-translation-sync#671 there). #192 survives: it is the newer issue, carries the security label, and already scopes the canonical → harness → estate rollout.

Both items from this issue were copied into #192 before closing, so nothing is lost — the permissions: contents: read block and the github.event.issue.pull_request requirement are now checklist items there.

Worth recording why this is not already fixed. The comment above expected the permissions half to land with #161 (Wave 1, PR D). Verified against main post-v0.24.0, it did not: generateSourceWorkflowYaml in src/cli/commands/setup.ts still emits no permissions: block, no author_association gate, and no issue.pull_request requirement — #161's composite guard is merged-PR ∨ resync-comment only. So both gaps described here are live in the canonical template and on every deployed instance except myst#979, which carries the fixed shape to copy from.