[kaniini]

The swap-over to the automated rebase dropped two boot performance commits from edera/6.18-lts that edera/mainline still had: f9a5aae (early CPU frequency from the hypervisor) and bb56add (wake the boot device wait when a backend changes state). Nothing noticed until they were ported by hand in #28. The per-PR backport can't catch this kind of drop, because it only ever looks at the PR that just merged.

This adds a weekly backstop. kernel-nightly.yml gets an audit input that runs the new lts-audit.yml:

• prepare (no model): runs pending-backports.sh with the same skip list the backports use (.automation/backport-skip plus the commits of no-backport PRs) to list every Edera commit on mainline that the LTS tree lacks. It also matches each missing commit by subject to open PRs into edera/6.18-lts and to mainline PRs labelled backport-waiting / backport-needs-attention.
• triage (Claude, read-only token, read-only git allowlist): follows .automation/skills/lts-audit/SKILL.md. For each commit not already in flight, it says whether the commit is really missing, was ported in another form, is already in linux-6.18.y, or doesn't apply to 6.18.
• publish: keeps a single issue, edera/6.18-lts is missing commits from edera/mainline. Each run edits the issue in place, posts a comment only when the set of missing commits changes, and closes the issue once nothing is missing. The list comes from git. Claude's notes only annotate it and can never remove a commit from it.

The schedule has to live on the default branch, so it is in #54 (lts-audit-trigger.yml, Mondays 09:41 UTC). Land this one first: the trigger dispatches with -f audit=true, which fails until this copy of kernel-nightly.yml has the input.

No new repository configuration. It uses the same REBASE_FEDERATION_RULE_ID / Anthropic identity variables as the dispatched backports, which already accept this subject.

Testing

• Ran pending-backports.sh locally against LTS just before chore(port): port boot performance improvements to 6.18-lts #28 (b236e48cab39^). It lists f9a5aae and bb56add (as rebased today, 8443f903deec / 6f15209388fb) plus the 10 other commits that landed with them. Against the current tip it lists nothing, so the first run should find the trees in sync and file nothing.
• Dry-ran the publish step with gh stubbed: it creates the issue, refreshes an unchanged set without commenting, comments with "newly missing / no longer missing" when the set changes, and closes the issue when in sync.
• All run: blocks pass bash -n. actionlint and shellcheck weren't available locally, so the selftest workflow is the first lint.