feat: trigger can-be-merged re-evaluation on review thread resolution

[rnetser]

Summary

Add handling for pull_request_review_thread webhook events to trigger can-be-merged re-evaluation when review threads are resolved.

Problem / Motivation

When required_conversation_resolution is enabled, can-be-merged fails if there are unresolved review threads. However, there is no event handler for when threads get resolved, so can-be-merged never re-runs unless another trigger fires (label change, check run completion, etc.).

Running the check on every pull_request_review_comment event would be wasteful since that fires on every comment, not just resolution changes.

Requirements

1. Handle the pull_request_review_thread webhook event (action: resolved). This event fires only when a thread's resolution status changes.
2. Optimization: "last thread resolved" gate — Before running the full check_if_can_be_merged, query get_unresolved_review_threads() first:
   • If count > 0 → skip (other threads still unresolved, can-be-merged would fail anyway)
   • If count == 0 → run full can-be-merged check
3. This means resolving 10 threads results in 10 cheap GraphQL calls but only 1 full can-be-merged evaluation.

Deliverables

• Add pull_request_review_thread event routing in github_api.py process() method
• Add event to example configs (examples/.github-webhook-server.yaml)
• Add tests for the new event routing
• Skip processing when required_conversation_resolution is disabled
• Skip repo cloning when unresolved threads remain (optimization gate)

Notes

• The pull_request_review_thread event is a distinct GitHub webhook event, separate from pull_request_review_comment.
• It fires only on thread resolution/unresolve, making it ideal for this use case.