Strip write capability from the untrusted-triggered claude.yml run

[Jartans-Familiar]

Summary

author_association gates this trigger, but the field cannot tell a human org member from a machine account in the same org — every agent workforce account is MEMBER, so every agent run (not just outside attackers) passed a gate meant to exclude untrusted principals. Row A of JAR-681. Per the accepted bar (JAR-687): tightening the author_association list is explicitly rejected as a fix — it removes legitimate humans while any machine holding COLLABORATOR still passes. The capability has to go, not the guard.

• Mint the App token with read-only permission-contents/issues/pull-requests instead of write.
• Drop the matching job-level permissions: block to read-only.
• Remove --dangerously-skip-permissions.
• Corrected a stale comment on the if: gate that claimed the association check "blocks the pwn-request path" via a write-scoped token — the token is no longer write-scoped, and the checkout was already pinned to github.ref_name (never fork-PR code), so that framing was already inaccurate before this fix.

scaffold is our published template — every downstream fork inherits this workflow and this defect. Forks should pull this fix (or the equivalent) into their own claude.yml.

Reproduction test

tests/test_claude_workflow_security.py reads the shipped .github/workflows/claude.yml and asserts no write scope is minted and permission checks aren't skipped. Verified fail-before / pass-after against base revision a502e218f9ed3800c74f255247a8fd1eb1708691:

• Before: both tests fail — job-level contents: write and --dangerously-skip-permissions present.
• After: both pass. Full suite is green.

Test plan

• ruff check .
• ruff format --check .
• pytest -m "not integration" (18 passed, including the new regression test)

JAR-687