private repo 会出现 author_association 判定失败

[Terry-Mao]

建议改成这个规则：

允许：

• author_association 是 OWNER / MEMBER / COLLABORATOR
• 或者 repo 是 private 且 author_association 是 CONTRIBUTOR，并且实时 API 查到该用户对 repo 有 write / maintain / admin 权限

拒绝：

• private repo 的 CONTRIBUTOR 但只有 read / triage 权限
• public repo 的普通 CONTRIBUTOR

这样能解决你这次误判，也不会把 /fix 开给所有历史贡献者。

实现点：

• 在 prepare_pr_comment_context.py 里，当 association 不在允许列表时，调用：
  repos/{owner}/{repo}/collaborators/{user}/permission
• 同时查 repo private 状态，或者从 PR payload 的 base.repo.private 读。
• permission in {admin, maintain, write} 就授权。
• skip reason 改成能说明是 association 失败还是 permission 失败。

这比直接把 CONTRIBUTOR 加进 AUTHORIZED_ASSOCIATIONS 安全得多。

[github-actions]

Triage summary

Confirmed as a workflow authorization bug in respond-to-pr-comment.

The current gate in .github/scripts/prepare_pr_comment_context.py uses AUTHORIZED_ASSOCIATIONS = {"OWNER", "MEMBER", "COLLABORATOR"} and computes authorization directly from the trigger comment or review author_association. That means CONTRIBUTOR is always skipped with an unauthorized association reason, even for a private repository where the actor may have write, maintain, or admin permission.

The likely fix area is the PR comment context preflight: keep the existing safe allowlist for OWNER, MEMBER, and COLLABORATOR, and add a private-repository permission fallback for CONTRIBUTOR before deciding should_run. Regression coverage should live in tests/test_prepare_pr_comment_context.py, including private write-capable contributors, private read/triage-only contributors, and public contributors.

Duplicate check: no duplicate was flagged. The candidate list has related PR-comment workflow background, but fewer than two candidates match this exact private-repo CONTRIBUTOR authorization failure.