ci: backport to ESR and ESR-1 release branches (#27460)

## What

Extend the backport workflow so the `backport` label fans out to **every
actively supported release channel**, not just the latest three minors.

Target branches are now the union of:

- the latest 3 `release/2.X` branches (mainline `n`, stable `n-1`,
security `n-2`), and
- the active **ESR** and **maintenance ESR (ESR-1)** branches.

The set is de-duplicated, so a branch that is both stable and ESR (today
`release/2.34`) is backported once. Dry-run against the current branch
list yields `release/2.29`, `release/2.33`, `release/2.34`,
`release/2.35`.

## Why

ESR / ESR-1 are designated biannually and can sit well below the top-3
window, so the previous `head -3` heuristic silently skipped them (e.g.
the maintenance ESR `release/2.29`). The current ESR was only covered by
coincidence when it happened to equal stable.

## Changes

- Add `scripts/release_channels/esr_versions.txt` as the single source
of truth for active ESR minors.
- `scripts/update-release-calendar.sh` now reads that file instead of a
hardcoded `ESR_VERSIONS` array (calendar output verified unchanged).
- `backport.yaml` `detect` job unions the latest 3 branches with the ESR
branches (existence-checked, warns and skips missing ones) and
de-duplicates.
- Backport PRs now get a `backport/v<version>` label, mirroring
`cherry-pick.yaml`, with `issues: write` added to create the label.

### Resilience to partial failures

Even with the independent matrix (`fail-fast: false`), a single branch's
job could previously abort without leaving anything behind, forcing the
remaining branches to be backported entirely by hand. Fixed so each
branch always ends with a PR (real or placeholder):

- Label, assignee, and reviewer are attached **after** the PR is
created, as best-effort steps. Requesting review from / assigning the PR
author is rejected by GitHub, which previously aborted `gh pr create`
under `set -e` and left no PR.
- Idempotency now keys off an existing backport **PR** rather than the
branch, and an existing backport branch is reused instead of bailing, so
a re-run recovers a branch that was pushed before its PR was opened.
- The workflow now comments on the original PR with each created
backport link, flagging conflicts that still need manual resolution.
- Conflicting cherry-picks continue to open a placeholder PR with
copy-paste resolution steps.

## Validation

- `actionlint`, `shellcheck -x`, and `zizmor` all pass.
- Re-ran `update-release-calendar.sh`; ESR statuses (`2.29 Extended
Support Release`, `2.34 Stable (ESR)`) are identical after the refactor.
- Dry-ran the detection logic against the live branch list (see set
above).

<details>
<summary>Implementation plan</summary>

# Plan: Backport to all supported release channels (mainline, stable,
security, ESR, ESR-1)

## Goal

The backport GitHub Action should open cherry-pick PRs against every
actively supported release branch:

| Channel | Meaning | Example today |

|-------------------------|-----------------------------|----------------|
| Mainline | last release (n) | `release/2.35` |
| Stable | n-1 | `release/2.34` |
| Security Support | n-2 | `release/2.33` |
| ESR | current Extended Support | `release/2.34` |
| Maintenance ESR (ESR-1) | previous ESR still patched | `release/2.29`
|

All channels map to `release/2.X` branches.

## What we targeted before

`.github/workflows/backport.yaml` took the exact `release/2.X` branches,
sorted by minor descending, and kept the top 3
(mainline/stable/security). ESR and ESR-1 are not derivable from version
ordering, so the maintenance ESR was silently skipped.

## Source of truth for ESR branches

`scripts/update-release-calendar.sh` already encoded the active ESR
minors (`ESR_VERSIONS=(29 34)`), driving the release calendar. Rather
than maintaining a second list, this list was extracted into a shared
data file consumed by both the calendar script and the workflow.

## Changes

1. Extract the ESR minors into
`scripts/release_channels/esr_versions.txt`; update
`update-release-calendar.sh` to read it.
2. Extend the `detect` job to emit the union of the top-3 branches and
one `release/2.<minor>` per ESR entry, existence-checked and
de-duplicated.
3. Add per-release `backport/v<version>` labels (with `issues: write`),
mirroring the cherry-pick workflow.

## Assumptions

- Major version is always `2` (matches existing code).
- The ESR list is maintained manually when ESR versions change.
- `cherry-pick.yaml` stays single-branch and is out of scope.
- Missing ESR branches are skipped with a warning, not a failure.

</details>

---
*Opened by Coder Agents on behalf of @f0ssel.*

scripts/release_channels/esr_versions.txt

@@ -0,0 +1,12 @@
+# Active ESR (Extended Support Release) versions.
+#
+# This file is the single source of truth for the active ESR set. It is
+# consumed by:
+#   - scripts/update-release-calendar.sh (release calendar in
+#     docs/install/releases/index.md)
+#   - .github/workflows/backport.yaml (backport target branches)
+#
+# Update this list when a new ESR version is designated or an old one reaches
+# end of life.
+2.29
+2.34

scripts/update-release-calendar.sh

@@ -8,17 +8,23 @@ set -euo pipefail
 # tag for each minor release.
 #
 # ESR (Extended Support Release) versions are biannually released and receive extended
-# maintenance. Update the ESR_VERSIONS array below when new ESR versions are designated
-# or old ones reach end of life.
+# maintenance. The active ESR set is maintained in scripts/release_channels/esr_versions.txt,
+# which is also consumed by .github/workflows/backport.yaml. Update that file when new ESR
+# versions are designated or old ones reach end of life.
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 
 DOCS_FILE="docs/install/releases/index.md"
+ESR_VERSIONS_FILE="${SCRIPT_DIR}/release_channels/esr_versions.txt"
 
 CALENDAR_START_MARKER="<!-- RELEASE_CALENDAR_START -->"
 CALENDAR_END_MARKER="<!-- RELEASE_CALENDAR_END -->"
 
-# Known active ESR (Extended Support Release) minor versions.
-# Update this list when new ESR versions are designated or old ones reach end of life.
-ESR_VERSIONS=(29 34)
+# Known active ESR (Extended Support Release) minor versions. The shared source
+# of truth stores full major.minor versions; extract the minor component, since
+# the calendar logic below is scoped to the 2.x line. Blank lines and '#'
+# comments are ignored.
+mapfile -t ESR_VERSIONS < <(grep -vE '^\s*(#|$)' "$ESR_VERSIONS_FILE" | cut -d. -f2)
 
 # Check if a minor version is a known active ESR version.
 is_esr_version() {