Relax approval check: any repo member's approval counts (not just maintainer team)

[potiuk]

The current rule that gates certain triage actions on a maintainer-team approval should be relaxed: any repo member's approving review counts.

Why: members who are not on the maintainer team frequently do high-quality first-pass reviews; requiring a second maintainer pass creates artificial bottlenecks.

Acceptance

• Identify every place the bot currently checks "approved by maintainer".
• Replace with "approved by any user with MEMBER association" (GitHub's author_association field on review objects).
• Document the change in the relevant skill / rule reference.

[andreahlert]

Did a full sweep of approval gates and author-association checks across the skills + tools. Findings: every place that gates on reviewer association already accepts MEMBER alongside OWNER/COLLABORATOR. Inventory:

Triage filters / decision table (.claude/skills/pr-management-triage/classify-and-act.md)

• F1 (line 44): authorAssociation in {OWNER, MEMBER, COLLABORATOR}
• F5a (line 48): COLLABORATOR/MEMBER/OWNER
• F6 (line 50): same union, with state in {COMMENTED, CHANGES_REQUESTED, APPROVED}
• merit_discussion_thread_present (line 285): same union
• No-collaborator-engagement clock (line 518): same union

Stats classify (.claude/skills/pr-management-stats/classify.md)

• is_triaged, is_engaged, is_ai_triaged, is_untriaged all use IN (OWNER, MEMBER, COLLABORATOR) (lines 25, 52, 77, 112, 330)

Code review selectors (.claude/skills/pr-management-code-review/selectors.md)

• collab:true/false table line 437: MEMBER matches collab:true

Stale sweeps (.claude/skills/pr-management-triage/stale-sweeps.md)

• last_maintainer_comment_at line 61: COLLABORATOR/MEMBER/OWNER

Tooling (tools/pr-management-stats/reference.py)

• COLLAB_ASSOCIATIONS = {\"OWNER\", \"MEMBER\", \"COLLABORATOR\"} (line 71)

References to maintainer-team that remain are not approval gates:

• pr-management-mentor uses maintainer_team_handle (@<org>/<team>) for hand-off mentions, not gating.
• pr-management-code-review/SKILL.md golden rule 7 talks about not approving while another maintainer's REQUEST_CHANGES review is pending, but the underlying selector resolves through unresolved_threads_only, which is MEMBER-inclusive.
• pr-management-code-review/selectors.md:213 mentions "maintainer (or maintainer-team)" in the CODEOWNERS context, not as an approval check.

So acceptance criterion 1 is satisfied as a no-op. Question: is there a specific gate you had in mind that I missed (e.g., the is_bot:false AND CODEOWNERS path, or a future Mode D auto-merge rule not yet in tree), or can this be closed as already-implemented?

If you want, I can still land a small docs commit explicitly stating "MEMBER association counts as an approver" in the code-review skill's preamble so the policy is discoverable without grepping enum unions, just say the word.