feat: add port-to-next label for forward-porting merged PRs

[PhilWindle]

Summary

Adds a generic port-to-next label — the mirror image of the existing backport-to-* labels, but with a single fixed target.

When a merged PR carries port-to-next, its merge commit is cherry-picked onto an accumulating port-to-next-staging branch, which opens/updates one PR directly into next. This gives us a one-click way to forward-port a fix landed on a release line into next.

How it works

Reuses the existing backport machinery rather than building a parallel system:

• scripts/backport_to_staging.sh — honours optional STAGING_BRANCH / STAGING_PR_TITLE / STAGING_PR_LABELS env overrides; defaults preserve today's backport-to-* behaviour, so the /backport skill and manual callers are unaffected. Labels are applied on both PR creation and a pre-existing staging PR.
• .github/workflows/backport.yml — the label check now matches backport-to-,port-to-next. A resolve step maps the label family to (target, staging branch, PR title, labels, verb): port-to-next → target next, staging port-to-next-staging, labels ci-no-squash. port-to-next takes precedence if both families are present. Success/failure comments and the Slack + ClaudeBox conflict dispatch use the resolved values.
• merge-train-update-pr-body.yml — port-to-next-staging added to the push triggers so the PR body's commit list stays current.
• merge-train-auto-merge.yml — a new BRANCH_PATTERN=port-to-next (8h inactivity) auto-merge job, matching the backport-train job.
• .claude/claudebox/backport.md + merge-train-infra skill — document the port variant.

The port-to-next GitHub label has been created on the repo.

Daily forward-port sweep

In addition to the per-PR label, a scheduled job keeps next fed with everything on the v5-next release line:

• .github/workflows/port-v5-next-to-next.yml — runs daily at 06:30 UTC (and on workflow_dispatch, with an optional source_branch input).
• scripts/port_to_next.sh — checks out the long-lived port-v5-next-to-next branch, merges both next and v5-next into it, and — if that produces a delta — opens/updates one ci-no-squash PR into next.

The branch is long-lived and accumulating, so any conflict resolution pushed to it is preserved across runs (fast-forward push). Once the PR is merged (the branch becomes an ancestor of next), the next run rebuilds it fresh from next with a --force-with-lease push; a run with no delta over next closes the stale PR.

On a merge conflict the run does not bail: it commits the conflicted merge (markers included) so the PR is still opened/updated as a resolution target, and posts the PR link + conflicted files to #backports. Resolve by checking out the port branch, fixing the markers, and pushing. This PR is intentionally not auto-merged — it is left for human review.

Notes

• The staging PR targets next, which enforces squashed PRs, so it carries ci-no-squash to allow the accumulated commits through squashed-pr-check.yml.
• Tradeoff (shared with the backport staging branches): ports accumulate into one staging PR, so a single conflicting port can hold up the batch until resolved.

Testing

Label-resolution logic exercised locally for all cases (port-only, backport, precedence, no-match); the CREATE_ARGS label plumbing, script syntax (bash -n), verb capitalisation, and YAML validity all checked.