feat(link-backport-prs): link backport PRs to matching Linear sub-issue

[Piotr1215]

Summary

Backport PRs opened by sorenlouv were never connected to the per-release-line Linear sub-issues ([0.34] Copy of ENG-x) that track each maintenance line. Those sub-issues stayed open after their backport merged, so patch-release tracking drifted and had to be reconciled by hand.

This adds a link-backport-prs composite action and wires it into the shared backport.yaml reusable workflow. After the backports are created, it links each one to the matching Linear sub-issue by adding Fixes <id> to the backport PR body, so the right sub-issue closes when the backport merges.

This implements the linking step described in Denise's comment on DEVOPS-693 (the authoritative spec) and step 6.1 of the "WIP: Patch Issue Management" Notion doc.

How it works

The trigger is the GitHub side, not Linear: the backport PR only exists after the source PR merges and sorenlouv runs, which a Linear webhook never sees. So the step runs inside backport.yaml, in the same job that creates the PRs. For each backport-to-vX.Y label on the merged source PR:

1. Resolve the source PR's Linear issue (the parent) via Linear attachmentsForURL, falling back to a TEAM-123 identifier parsed from the branch or body.
2. Reconstruct the backport PR sorenlouv created (head: backport/vX.Y/pr-<src>, base: vX.Y).
3. Find the sub-issue under the parent whose title carries the release-line prefix ([0.34] or [v0.34]).
4. Append Fixes <sub-issue-id> to that backport PR's body, unless it already references the issue.

Matching is by title prefix, not milestone: the backport-copy sub-issues do not reliably carry a patch milestone and can live in the parent's project, so the title is the dependable key. Verified end to end against a real family: vcluster#3993 -> parent ENGCP-906 -> ENGCP-913 [0.34] and ENGCP-943 [0.35].

Key Changes

• New .github/actions/link-backport-prs Go composite action (modeled on linear-pr-commenter), with unit tests for the matching logic.
• backport.yaml: optional linear-token secret and an advisory step that runs the action after sorenlouv.
• Makefile target test-link-backport-prs, CI workflow test-link-backport-prs.yaml, README entry, and regenerated docs/workflows/backport.md.

Backward compatibility

Strictly additive. The linear-token secret is optional, the step is continue-on-error: true, and the action exits 0 and no-ops when no token is provided. Existing callers (e.g. vcluster on @backport/v1) are unaffected until the coordination tag is moved.

Notes / dependencies

• This is the linking half. It only links sub-issues that already exist. Those [X.Y] Copy of ... sub-issues are meant to be created by the linear-webhook-service needs-backport automation; that automation requires the issue to have a milestone and be in a patch-release project, and currently the copies are often created by hand. The linker works regardless of who created them, but its end-to-end value depends on the copies existing.
• Resolving the parent uses Linear attachmentsForURL; if Linear's schema differs in practice this is the first thing to validate against a live token.

TODO before this takes effect in production

• Push the action tag link-backport-prs/v1 and move the backport/v1 coordination tag to this commit (the workflow references the action by @link-backport-prs/v1, following the notify-release / release-notification pattern).
• Have callers (vcluster, vcluster-pro, loft-enterprise) pass linear-token: ${{ secrets.LINEAR_API_TOKEN }} to enable linking.

Closes DEVOPS-693