automation: propose a 6.18-lts backport for each merged mainline PR

[kaniini]

Every PR merged into edera/mainline gets its own proposed backport PR into edera/6.18-lts, unless it carries the no-backport label. All of this runs on edera/6.18-lts. The mainline side is only a trigger (companion PR), which runs this tree's kernel-nightly.yml with backport_pr=<N>.

Flow for one mainline PR

1. Plan, done by scripts before Claude runs.
   • Works out which of the PR's commits 6.18-lts still lacks. Matching is by patch content first, then by title.
   • Skips automation-only commits, anything in .automation/backport-skip, and commits from PRs labelled no-backport.
   • Order: if an earlier mainline Edera commit that touches the same files is still missing on 6.18-lts, the PR is labelled backport-waiting and Claude doesn't run.
2. Claude cherry-picks the commits with -x onto the 6.18-lts tip and adapts them where 6.18 differs. It builds, then writes a report. It can also declare a dependency that the file check misses (Status: waiting).
3. Independent checks. verify-backport.sh checks that the result is the tip plus exactly these commits, in order, each with its source's title and +/- lines. Then x86_64 and arm64 builds.
4. Publish. It always opens, or refreshes, backport/edera-6.18-lts/pr-<N>, and never pushes edera/6.18-lts.
   • Differences found by the checker, failed builds and open questions are flagged at the top of the PR.
   • The mainline PR gets a single status comment that is kept up to date.
   • When there's nothing to propose, the mainline PR gets backport-needs-attention instead.
5. Landing is the merge button with Rebase and merge. A backport only adds commits on top of the tree, so it doesn't hit the conflict problem that blocked approve-to-land on rebase PRs.

Retries and refreshes

• When a backport PR merges here, every backport-waiting mainline PR is dispatched again (lts-backport-merged.yml).
• After each nightly rebase, the same happens. Open backport PRs that the rebase made unmergeable are also prepared again from the new tip (retry-backports.sh --stale).
• If the tree is rebased while a backport is running, that run dispatches itself again rather than proposing something built on the old tip.

Checked locally

• All three self-test scripts pass. The backport suite has new cases for ordering and blocking.
• shellcheck and actionlint are clean.
• I ran the planning step against the real trees for every merged mainline PR:
  • security: openpax: disable OpenPaX by default #20, feat(xen): permit ballooning at 2MiB when possible #8 and openpax: forward-port OpenPaX hardening series to mainline #4 have nothing to do, because 6.18-lts already has them;
  • automation: trigger the edera/6.18-lts rebase nightly #18 only touches automation, so it is ignored;
  • xen: improve boot time on PVH by 200ms #7 (xen: improve boot time on PVH by 200ms) has both of its commits missing on 6.18-lts, with nothing blocking them.

Not yet exercised on GitHub

The workflows themselves haven't run yet.

• Inputs: whether GitHub accepts a backport_pr input that mainline's kernel-nightly.yml lacks. I expect it to check this branch's copy of the file.
• Comment and labels: the status comment and the labels on the mainline PR.
• Claude: the backport run itself.

A manual run with backport_pr = 7 would exercise all of it.