backport: deploy backport-branch automation workflows to active backport branches

## Summary

Several workflows trigger on events scoped to `backport-*` branches — `sync-backport-changelog.yml` (#19215) on `push`, `post-backport-branch.yml` (#19214) on `pull_request`, and the owner-sync CI check (#19686) on `pull_request` — and GitHub Actions resolves both event types from the workflow files present **on the branches involved in the event**, not from `main`:

- `push` workflows execute from the workflow file on the branch being pushed to.
- `pull_request` (non-`pull_request_target`) workflows execute from a merge of the PR's head and base branches.

In both cases, if the workflow file is absent from the backport branch, GitHub never schedules it — the automation is silently skipped for every existing branch.

This issue covers the one-time migration to add these workflows (and any scripts they call) to all currently active branches.

This issue is a **follow-up to #19215, #19214, and #19686** — existing branches will not benefit from this automation until the migration is run, but each of those issues can ship and be useful for all newly created branches immediately.

## Background

The existing backport branches were created from commits that predate the backport automation work. The `backport_branch.sh` script already copies the required files when creating new branches, so new branches are covered from day one. The gap is the existing active branches, which need a one-time migration after #19215, #19214, and #19686 ship.

There is no workaround via `workflow_run` or `workflow_dispatch` — both `push` and `pull_request` events on a backport branch will only fire workflows that already exist on that branch (or, for `pull_request`, on the head branch cut from it).

## Deliverables

### One-time migration script

A script (or documented manual procedure) that, for each active branch in `.backports.yml`:

1. Checks out the backport branch
2. Copies `.github/workflows/sync-backport-changelog.yml`, `.github/workflows/post-backport-branch.yml`, the owner-sync CI check workflow introduced in #19686, and any scripts they call (resolved at implementation time from each issue's deliverables) onto the branch
> Consider reusing the same approach `backport_branch.sh` already uses to copy required files from `main` when creating new branches (`git checkout main -- ` per file/directory) instead of building a separate ad hoc copy mechanism for this migration script.
3. Opens a PR against the backport branch with the label `automation`

The script can be run once by the ecosystem team after #19215, #19214, and #19686 ship. A migration PR per branch is preferred over a force-push so that the addition goes through CI and review.

> **Note:** the exact set of files to copy is determined by #19215's, #19214's, and #19686's final implementations. Coordinate with those issues before running the migration.

## Considerations

- **File set may grow:** if future issues add more workflows or scripts that need to run on backport branches, the migration script should be extended and re-run. This is now the third workflow requiring this treatment — worth defining an explicit manifest of "files required on every backport branch" rather than continuing to hard-code individual filenames.
- **#19686 has two deliverables — only one belongs here:** syncing owners into `manifest.yml`/`CODEOWNERS` at backport-PR-creation time lives in `backport_apply.sh`, invoked by automation from `main`'s checkout — it is not branch-resident and needs no migration. The CI check enforcing owner sync on PRs *targeting* a backport branch is the part that matters here; confirm with #19686's implementation whether it's a new workflow file (add to the copy list above) or a step added to an already-migrated file (the migration would then need to push updates to previously migrated branches, not just an initial copy).
- **Migration ordering:** run the migration only after #19215, #19214, and #19686 are fully merged and stable. Running it against a partially implemented workflow risks pushing a broken file to production branches.

## Acceptance criteria

- [ ] All currently active branches listed in `.backports.yml` have `sync-backport-changelog.yml`, `post-backport-branch.yml`, and the owner-sync CI check (and their dependencies) present
- [ ] Pushing to any active backport branch after migration triggers `sync-backport-changelog.yml` correctly
- [ ] Opening an `auto-backport` PR against any active branch after migration correctly triggers `post-backport-branch.yml`
- [ ] All currently active branches enforce the owner-sync CI check from #19686 on PRs targeting them
- [ ] Migration PRs are labelled `automation` and do not trigger `auto-backport.yml` on merge