Unassign blocked reviewers on community contribution MRs

What this does

Unassigns reviewers whose GitLab account can no longer receive a review from open Community contribution merge requests, and comments to say which requests were removed and why, so the author can line up an active reviewer instead of waiting on a request that cannot arrive.

Background: gitlab-com/www-gitlab-com#35556 - the contributor platform can request a review from a team member whose account is later blocked because they have left. The request reaches no one and the merge request can sit idle for weeks.

How

lib/blocked_reviewer_helper.rb and plugins/blocked_reviewer_helper.rb add a BlockedReviewerHelper that reads each reviewer's account state straight off the merge request resource the policy has already loaded. It makes no API calls. A reviewer counts as blocked only when state is present and is not active, so a payload that cannot tell us leaves the reviewer alone rather than unassigning on a guess.

policies/community/hygiene/unassign-blocked-reviewers.yml acts on an open community merge request that has at least one such reviewer: it removes them with the gem's remove_reviewers action and comments naming who was removed, with a link to request a review on the contributor platform. It is gated on community_automation_in_scope?, matching ping-inactive-author.yml - full gitlab-org, part_of_product only on gitlab-com.

.gitlab/ci/frequency/daily-weekdays.yml gains two jobs, one for gitlab-org (group 9970) and one for gitlab-com (group 6543). This is daily-weekdays.yml rather than daily.yml, where ping-inactive-reviewers lives, because daily.yml is at the 85-job cap.

spec/lib/blocked_reviewer_helper_spec.rb covers the behaviour.

Why there are no API lookups

An earlier revision called /users?username= once per reviewer. That was redundant: the merge request resource already carries each reviewer's account state. Note this is a different field from the identically named state on the /merge_requests/:iid/reviewers endpoint, which is the review state (unreviewed, approved); lib/community_contribution_helper.rb:34 documents that distinction in the other direction. Dropping the lookups removes roughly 1900 API calls per run across gitlab-org.

There is also no marker label any more. Once the blocked reviewers are removed the rule stops matching by itself, so nothing is needed to keep it from commenting twice.

Validation

spec/lib/blocked_reviewer_helper_spec.rb passes with 8 examples. Each one was checked to actually bite, by reverting the missing-state guard and by inverting the active comparison and confirming the expected examples fail. RuboCop is clean, and the policy passes spec/policies/no_quick_actions_spec.rb.

The helper was also run against a real payload, gitlab-org/gitlab!261672, which has one blocked reviewer and GitLabDuo active: it resolves to the blocked account only and leaves Duo assigned. The policy dry run matched 29 open Community contribution merge requests with a blocked reviewer, 24 in gitlab-org and 5 in gitlab-com.

Not covered here: the fork pipeline has no bot token, so the policy dry run has to be run from the Quality side.

Closes #1905 (closed).