ci: open merge-back MR for leading-edge backports

What does this MR do?

Makes release:backport open a merge-back MR to the default branch after it tags a leading-edge backport, so the new tag becomes reachable from the default branch.

Why

release:prepare derives the next version with semantic-release, which counts only tags merged into the default branch (git tag --merged). The backport flow tags vX.Y.Z-gitlab directly on an unmerged release/vX.Y.Z branch and never merges back. So a backport whose version is higher than the default branch's highest release is invisible to release:prepare, which recomputes and reuses that version, then fails pushing the already-existing release branch.

That is exactly what happened with 4.40.1 (job 14962704350). The one-off merge-back for 4.40.1 is !2893 (merged). This MR prevents recurrence.

What to know

• The merge-back fires only when the backport version is strictly above the highest release reachable from the default branch. Old-line backports (a patch on a maintenance line below the default branch's max) are skipped: no collision exists there, and merging an old base into the default branch would conflict.
• The created MR sets squash=false. Squashing would replace the tagged commit, making the tag unreachable from the default branch again. The job comment and the MR body both call this out.
• The MR is assigned to the user who ran the backport (GITLAB_USER_ID).

Test plan

• python3 -c "import yaml; yaml.safe_load(...)" confirms the file is valid YAML.
• bash -n on the extracted logic confirms shell syntax.
• Leading-edge detection passes seven cases including version-sort traps (4.9.0 vs 4.10.0, 4.40.10 vs 4.40.2): 4.40.0→4.40.1 fires, 4.41.0→4.40.2 skips, equal versions skip, empty baseline skips.
• Against the live repo, git tag --merged origin/master yields 4.40.0, so a 4.40.1 backport correctly triggers the merge-back.

Related to release:prepare job 14962704350

Author checklist

• CODEOWNERS Review: This MR requires approval from at least one CODEOWNER per category/file.
  • If codeowners are absent or the change is urgent, any registry maintainer can temporarily disable CODEOWNERS reviews in the project settings. When doing so:
    • Add a comment on the MR justifying the bypass
    • Mention/CC the designated codeowners in the MR for async review
    • Re-enable CODEOWNERS reviews in project settings once the MR is merged
  • If you lack permissions to disable CODEOWNERS reviews, reach out to the Engineering Manager (@jaime) or Senior Engineering Manager (@crystalpoole) for assistance.
• Assign one of conventional-commit prefixes to the MR.
  • fix: Indicates a bug fix, triggers a patch release.
  • feat: Signals the introduction of a new feature, triggers a minor release.
  • perf: Focuses on performance improvements that don't introduce new features or fix bugs, triggers a patch release.
  • docs: Updates or changes to documentation. Does not trigger a release.
  • style: Changes that do not affect the code's functionality. Does not trigger a release.
  • refactor: Modifications to the code that do not fix bugs or add features but improve code structure or readability. Does not trigger a release.
  • test: Changes related to adding or modifying tests. Does not trigger a release.
  • chore: Routine tasks that don't affect the application, such as updating build processes, package manager configs, etc. Does not trigger a release.
  • build: Changes that affect the build system or external dependencies. May trigger a release.
  • ci: Modifications to continuous integration configuration files and scripts. Does not trigger a release.
  • revert: Reverts a previous commit. It could result in a patch, minor, or major release.
• Change contains a breaking change - apply the breaking change label.
• Change is considered high risk - apply the label high-risk-change