ci: label user-prefixed backport branches too (#15105)

## The workflow does not catch the branches it exists for

`pr-label-backport.yaml`'s header states its purpose plainly —
*"Guarantees that
every backport PR carries the `backport` label, **whoever opened it**"*
— and
explains that manual backports are the case that matters, because
`pr-backport.yaml` only labels the PRs it creates itself, and hands off
to a
human when the cherry-pick conflicts.

But `isBackportBranchForBase` matched only the exact branch the workflow
generates:

```ts
const BACKPORT_BRANCH_PATTERN = /^backport-\d+-to-(.+)$/
```

A human finishing a conflicted cherry-pick does not produce that. They
produce
`<user>/backport-<pr>-to-<target>` — what `gh` and most local branch
conventions give you.

## This week's worked example

**#15102** and **#15103** (`jaeone94/backport-14984-to-core-1.49` and
`…-cloud-1.49`) were opened by hand after `pr-backport.yaml` failed on
#14984's cherry-pick, and carry the `backport` label **only because
someone
applied it manually**.

That matters because an unlabelled backport is invisible to
`backport-auto-merge.yaml` and `pr-assign-release-sheriff.yaml` — both
sweep
`gh pr list --label backport` — so it sits open until somebody notices.
Which
is exactly what #14018–#14021 are cited for in the workflow's own
header.

Surveying every backport-titled PR in the repo: the bot's
`backport-<n>-to-<target>` branches are all labelled, and the only
user-prefixed pair is the one that needed a human.

## Only the prefix widens

```diff
-const BACKPORT_BRANCH_PATTERN = /^backport-\d+-to-(.+)$/
+const BACKPORT_BRANCH_PATTERN = /^(?:.*\/)?backport-\d+-to-(.+)$/
```

The `\d+-to-` core and the existing base check still decide what counts
as a
backport, so this does **not** loosen the definition:

| branch | base | before | after |
| --- | --- | --- | --- |
| `backport-14979-to-core-1.49` | `core/1.49` | ✅ | ✅ |
| `jaeone94/backport-14984-to-core-1.49` | `core/1.49` | ❌ | ✅ |
| `jaeone94/backport-14984-to-core-1.49` | `cloud/1.49` | ❌ | ❌ *(target
≠ base)* |
| `glary/backport-resilient-partial-failure` | `core/1.49` | ❌ | ❌ |
| `deepme987/infra/backport-assign-author` | `main` | ❌ | ❌ |

The last two are real branches in this repo — *about* backporting rather
than
backports. A prefix must not turn them into one, and it doesn't: they
have no
`<digits>-to-` segment.

## Verification

`backport-label.test.ts` **16/16**, with three new cases covering the
prefixed
form, the prefixed-but-wrong-base rejection, and the two real
non-backport
branches above.

Mutation-checked rather than asserted green — reverting the regex to
`^backport-`
fails exactly one test (the new prefixed case) and leaves the other 15
passing.

## Disclosure

I hit this myself from the other direction. My manual backports
#15095/#15096
used `backport/<pr>-to-<target>` — a **slash** where the convention uses
a
hyphen. That one is genuinely off-convention rather than a gap in the
rule, so
this PR deliberately does **not** widen the pattern to bless it; I fixed
those
branches' labels by hand instead.

Co-authored-by: t <t@t.t>

Author: christian-byrne

scripts/cicd/backport-label.test.ts

@@ -93,6 +93,46 @@ describe('isBackportBranchForBase', () => {
       isBackportBranchForBase('backport-abc-to-cloud-1.47', 'cloud/1.47')
     ).toBe(false)
   })
+
+  it('recognises the user-prefixed form a human finishing a cherry-pick creates', () => {
+    // #15102 and #15103 are the worked example: opened by hand after the
+    // workflow's cherry-pick conflicted, and labelled by hand because this
+    // returned false for them.
+    expect(
+      isBackportBranchForBase(
+        'jaeone94/backport-14984-to-core-1.49',
+        'core/1.49'
+      )
+    ).toBe(true)
+    expect(
+      isBackportBranchForBase(
+        'deepme987/infra/backport-123-to-cloud-1.49',
+        'cloud/1.49'
+      )
+    ).toBe(true)
+  })
+
+  it('still checks the encoded target against the base when prefixed', () => {
+    expect(
+      isBackportBranchForBase(
+        'jaeone94/backport-14984-to-core-1.49',
+        'cloud/1.49'
+      )
+    ).toBe(false)
+  })
+
+  it('rejects a prefixed branch that only mentions backport', () => {
+    // Real branches in this repo. A prefix must not turn them into backports.
+    expect(
+      isBackportBranchForBase(
+        'glary/backport-resilient-partial-failure',
+        'core/1.49'
+      )
+    ).toBe(false)
+    expect(
+      isBackportBranchForBase('deepme987/infra/backport-assign-author', 'main')
+    ).toBe(false)
+  })
 })
 
 describe('planBackportLabels', () => {

scripts/cicd/backport-label.ts

@@ -31,7 +31,20 @@ export function toSafeBranchName(branch: string): string {
   return branch.replaceAll('/', '-')
 }
 
-const BACKPORT_BRANCH_PATTERN = /^backport-\d+-to-(.+)$/
+/**
+ * The optional leading path segment is what makes this useful for the manual
+ * backports this workflow exists to catch. `pr-backport.yaml` creates
+ * `backport-<pr>-to-<target>`, but a human finishing a conflicted cherry-pick
+ * by hand almost always ends up with `<user>/backport-<pr>-to-<target>` —
+ * that is what `gh` and most local conventions produce. Two such PRs appeared
+ * in one week (#15102, #15103) and had to be labelled by hand.
+ *
+ * Widening the prefix does not widen what counts as a backport: the
+ * `\d+-to-` core and the base check below still do that work, so branches
+ * like `glary/backport-resilient-partial-failure` — real branches in this
+ * repo, about backporting rather than backports — stay rejected.
+ */
+const BACKPORT_BRANCH_PATTERN = /^(?:.*\/)?backport-\d+-to-(.+)$/
 
 /**
  * True when `headRef` is the backport branch that `pr-backport.yaml` would