Gate each backport on its release manager's approval instead of the release/* label alone #8084

Task Summary

#6940 made backporting opt-out: a fix: PR into main is auto-labeled with every actively-supported release/* branch, and review is requested from each branch's release manager. That review request is advisory only — the label alone decides. Whatever release/* labels sit on the PR at merge time are cherry-picked to the release branch, whether or not the manager ever looked at it. A release manager has no way to say "not on my branch" short of watching for the PR and deleting the label before it merges.

Make the label a nomination and the manager's approval the decision: a fix lands on a release branch only once the manager configured for that branch in .github/release-branches.yml has approved the PR. Managers gate their own branch and nothing else, so approvals compose — with release/v1.2 and release/v1.3 both labeled, an approval from the v1.2 manager alone lands the fix on v1.2 and leaves v1.3 behind; both approving lands it on both; neither approving lands it on neither.

Scope:

1. The gate. In Direct Backport Push's discover step, filter the labeled targets by each manager's latest review state, before reading the much more expensive apply/build signals. A later CHANGES_REQUESTED or DISMISSED (what a stale-review dismissal produces) revokes an earlier approval; COMMENTED reviews never change one.
2. Cases that must not deadlock. A manager who authored the fix counts as approving it, since GitHub does not let anyone approve their own PR; a target whose entry configures no manager stays ungated; an unreadable review list holds every gated target back rather than guessing.
3. Make it visible. A skipped target otherwise leaves no trace — no cherry-pick, no draft backport PR, no check. The merged PR should get a comment naming the targets that were held back and whose approval each needs, and the pre-merge auto-label report should state the requirement up front so it is known before the merge rather than only after it.
4. Docs. .github/release-branches.yml, AGENTS.md, and CONTRIBUTING.md all currently describe the release/* label as what drives the backport; update them.

The behavior is keyed off release-branches.yml, so it applies to whatever branches are listed there — v1.1 and v1.2 today, v1.3 and v1.4 as they are cut, with no further workflow changes.

Task Type

• DevOps / Deployment / CI