CI: Auto cherry-pick to Gutenberg release branches

[cbravobernal]

What?

Adds .github/workflows/cherry-pick-gutenberg-release.yml — an Auto Cherry-Pick workflow for Gutenberg's own release branches, mirroring the existing WP Auto Cherry-Pick workflow (cherry-pick-wp-release.yml).

On merge of a PR to trunk labeled Backport to Gutenberg RC, it:

1. Resolves the target release branch as the highest release/X.Y (semver sort).
2. Cherry-picks the merge commit onto that branch and pushes.
3. Removes the Backport to Gutenberg RC label.
4. Comments the target branch + cherry-pick SHA on the PR.
5. On conflict, posts manual-resolution instructions (same as the WP workflow).

Why?

Today these picks are done by hand — e.g. #78848 opened a manual cherry-pick PR onto release/23.3. This automates the label-driven picks, the same way WP backports are already automated.

Design notes

• Versionless label. Gutenberg's two-week cadence makes a per-release label (like WP's Backport to WP X.Y Beta/RC) impractical, so the label carries no version. The target branch is resolved by picking the highest release/X.Y instead. The chosen target is commented on the PR so a wrong target (e.g. a label applied after stable shipped but before the next branch is cut) is easy to spot.
• Reuses the existing system: same pull_request_target trigger, same pinned action SHAs, same GUTENBERG_TOKEN secret (which bypasses release/* push protection — the restriction Backport to 23.3: 10 cherry-picks for stable #78848 worked around).

Not covered (still manual)

• CI-infra picks that aren't label-driven (e.g. browserslist / test-data freshness).
• Milestone assignment for changelog regen.

Testing

Workflow logic mirrors the proven cherry-pick-wp-release.yml 1:1, differing only in label match, target-branch resolution, and label cleanup. Needs a maintainer to validate on a real merge once landed.

🤖 Generated with Claude Code

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: cbravobernal <cbravobernal@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: arthur791004 <arthur791004@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

After recent events in the security world, are we still using pull_request_target?

[cbravobernal]

We are still using it. And the script is meant to run only in already reviewed and merged PRs. But happy to have a second opinion. @pkevan may help us?

[arthur791004]

Would it be better to also support "Backport to Gutenberg Minor Release" as well?

[cbravobernal]

Would it be better to also support "Backport to Gutenberg Minor Release" as well?

Gutenberg Minors are usually less common than cherry-picking to RCs before a point release, maybe we could do it in a different PR.