security(github): filter list_issues by trusted author_association (Closes #178)

[ytnobody]

Summary

• HERMIT can run against public repos where anyone can open an Issue whose body is then handed to an Engineer running locally with broad tool access (Bash(*) among it). Nothing previously verified the Issue author before it reached that pipeline.
• ListOpenIssues / ListAllIssues (internal/github/client.go) now filter out any Issue whose GitHub author_association is not in a trusted allowlist, via a new (*Client).isTrustedAuthor check applied inside listOpenIssuesFromRepo — the single call path both single-repo and multi-repo modes funnel through.
• Default allowlist (gh.DefaultTrustedAuthorAssociations): OWNER, MEMBER, COLLABORATOR only. CONTRIBUTOR / FIRST_TIME_CONTRIBUTOR / NONE are excluded by default.
• Configurable via a new harness.toml [security] trusted_author_associations key (cmd/hermit/main.go Config.Security), wired into both cmdServe and cmdDryRun via client.SetTrustedAuthorAssociations(...). An absent or empty config resolves to the same safe default — there is no configuration path that means "allow everyone."
• Excluded Issues are not silently dropped: each exclusion is logged via log.Printf (security: excluding issue #N in owner/repo ...: author_association="..." is not in the trusted allowlist).
• Because list_issues (internal/mcp/tools.go) only ever queues what ListOpenIssues/ListAllIssues return, excluded Issues automatically never reach assign_issue / create_worktree — no changes needed in internal/mcp.
• Added REQ-017 to REQUIREMENTS.md and TestREQ017_* tests in internal/github/req_test.go covering: default-safe-allowlist-when-unconfigured, empty-config-does-not-mean-allow-everyone, custom-allowlist-is-honored (case-insensitively), multi-repo filtering, and that the AuthorAssociation field is populated on surviving Issues.
• Updated existing internal/github tests (multi_repo_test.go, req_test.go) that assert real Issues survive ListOpenIssues/ListAllIssues to include an author_association in their fixtures, since the new default-deny behavior would otherwise filter them out.
• Documented the new config in README.md (new "Trusted Issue Authors" section) and cmd/hermit/templates/harness.toml.tmpl.

Assumptions

• Filtering happens once, in the internal/github client layer, rather than in internal/mcp or internal/readiness — this keeps a single point of enforcement and requires no interface changes in internal/mcp's githubClient consumer or its extensive existing test suite (which uses a fake in-memory implementation of that interface, unaffected by this change).
• Out of scope per the Issue: reducing the Engineer's Bash(*) permission is tracked separately in Engineer の Bash を allowlist ではなくサンドボックスで制限する（hermit init / doctor / README） #180.

Test plan

• go build ./...
• go vet ./...
• go test ./... (all packages pass, including new TestREQ017_* tests)

Closes #178

[ytnobody]

Superintendentによるレビュー(PR #187, Issue #178)

evaluate_risk の判定は HIGH(cmd/hermit/main.go, cmd/hermit/dryrun.go が cmd/ の高リスクパスに該当)。自動マージ対象外のため、人間の判断を待ちます。以下、実質的なレビュー内容です。

差分の内容確認

• internal/github/client.go: DefaultTrustedAuthorAssociations = ["OWNER", "MEMBER", "COLLABORATOR"] を追加。isTrustedAuthor は trustedAssociations が未設定/空の場合にこのデフォルトへフォールバックする実装で、「設定漏れ→全員許可」にならない設計はIssueの要求通り
• listOpenIssuesFromRepo(ListOpenIssues/ListAllIssues双方が経由する唯一の入口)でフィルタしており、除外されたIssueはassign_issue/create_worktreeの対象になり得ない
• 除外時にlog.Printfで理由(Issue番号・owner/repo・association)を記録しており、「黙って消える」ことを避ける受け入れ条件を満たす
• harness.tomlの[security] trusted_author_associationsからcmdServe/cmdDryRun双方に配線されている
• テスト(TestREQ015_*)は、デフォルト安全策・空設定でのフォールバック・カスタムallowlist・マルチリポジトリ・AuthorAssociationフィールドの4系統をカバーしており、受け入れ条件を満たしている
• CIは全て成功(Test/Lint/Security Scan)

懸念点

• REQUIREMENTS.mdのREQ-015が重複しています。PR feat(risk): promote control-plane paths to HIGH risk (Closes #179) #185(Issue 制御面(risk/permissions/readiness/harness.toml/.claude)への変更を HIGH に昇格し、自動マージから隔離する #179)およびPR fix(requirements): stop review-test self-reinforcing loop (Closes #182) #186(Issue review-test が自己増殖する — ハッシュ対象に実装状況が含まれ、解決作業自体が次の発火を確定させる #182)も同じ「REQ-015」番号を使っています。3件のうち2件以上をマージする際はリナンバーが必要です
• harness.tomlへの新設定キー追加自体は本Issueのスコープ内ですが、harness.tomlは別Issue #179で制御面パスとしてHIGH昇格対象になっています。今回のPRが先にマージされてもharness.tomlの構造自体は破壊的でないため問題はなさそうです

推奨

実装はIssueの受け入れ条件を過不足なく満たしており、安全側のデフォルト設計も適切です。人間による承認後のマージを推奨します。マージ時はREQ-015番号衝突の解消をお願いします。

[ytnobody]

⚠️ HERMIT: HIGH risk detected.
Reasons: [cmd/hermit/dryrun.go is in a high-risk path cmd/hermit/main.go is in a high-risk path]