chore(release): merge v4.40.1 backport into master

What does this MR do?

Merges the release/v4.40.1 backport branch into master so the v4.40.1-gitlab tag becomes reachable from master.

Why

4.40.1 was cut as a backport (release:backport), which tags v4.40.1-gitlab directly on the release/v4.40.1 branch and never merges back. release:prepare runs semantic-release on master, and semantic-release only counts tags merged into the branch it releases (git tag --merged). The backport tag is not reachable from master, so semantic-release recomputed 4.40.1 and release:prepare failed trying to re-push the already-existing release/v4.40.1 branch (non-fast-forward, job 14962704350).

Merging the branch back makes the tag reachable from master, so the next release:prepare computes 4.40.2 instead of colliding on 4.40.1.

Merge with a merge commit, do not squash

Squashing replaces commit b4c21f9e (the commit v4.40.1-gitlab points to), which would make the tag unreachable from master again and reintroduce the bug. The project default is squash-on, so uncheck squash before merging. merge_method is already merge, so a normal merge preserves the commit.

release:tag no-ops on this merge because v4.40.1-gitlab already exists.

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