automation: rebase edera/4.22 onto upstream staging-4.22 nightly

[kaniini]

Adds a nightly workflow in which Claude rebases edera/4.22 onto xen-project staging-4.22, then lands the result automatically if it is clean or opens a pull request for review if it is not.

How a night runs

1. prepare — fetches upstream. Stops if edera/4.22 already contains staging-4.22, or if an open rebase PR already covers the same pair of tips, so quiet nights never start the model.
2. rebase — Claude follows .automation/skills/upstream-rebase/SKILL.md: replay, resolve conflicts, fix build breaks in the commit at fault, build, audit any new XSAs (including whether each fix survived the replay), write a report. This job holds a read-only token and cannot push; the branch leaves it as a git bundle.
3. verify + build — judged independently, from the commit the run started from:
   • verify-upstream-rebase.sh: on the upstream tip, linear, no commit lost or gained (a changed patch-id is accepted only where the commit's own +/- lines are identical and just the hunk context moved), and the tree changed by exactly the upstream delta.
   • x86, arm64 defconfig, arm64 + PCI_PASSTHROUGH.
4. publish
   • Clean (checker passes, all builds pass): force-push edera/4.22 with --force-with-lease pinned to the starting tip; old tip kept as backup/edera-4.22-pre-rebase-….
   • Not clean: push rebase/edera-4.22/<date>-<old>-<upstream> and open a PR with the report and checker output. Approving it lands it via upstream-rebase-land.yml (the merge button would graft a second copy of the series). Older rebase PRs are closed as superseded.
   • No result: one standing issue, commented on each failed night.

Any conflict Claude resolves shows up as drift, so those nights always go to a human.

Safety

• The model never holds a write token. github_token is passed explicitly so the action does not mint its own.
• PR-triggered workflows (including the land workflow and the review checks) run the PR branch's own .github/ with repository secrets. publish therefore refuses to push anything, as edera/4.22 or as a PR, whose .github/, .automation/ or .review/ changes differ from upstream's changes to those paths.
• The land workflow requires the approval to be for the current head and the approver to have write access, and takes the expected edera/4.22 tip from the branch name, which cannot be edited on an open PR. If edera/4.22 moved, it pushes nothing.

Testing

• The checker passes the two real staging-4.22 rebases from 2026-09-03 and 2026-09-08, and on the latter reports the MEMF_zero commit as context-only, matching the manual audit at the time.
• .github/scripts/tests/verify-upstream-rebase.test.sh (8 cases, run by upstream-rebase-selftest.yml) builds a throwaway repo and checks that honest replays pass and that edited (with a repeated subject), dropped, added and merge commits and a stale base are refused. Mutation-checked: reintroducing an earlier checker bug makes it fail.
• The automation-path guard passes both real rebases and refuses one with an injected workflow file.
• actionlint and shellcheck clean.
• Not yet run in Actions; it needs the configuration below first.

Configuration needed before it can run

• A GitHub App installed on this repo with contents, pull-requests and workflows write, allowed to bypass the edera/4.22 rules: vars.REBASE_APP_CLIENT_ID, secrets.REBASE_APP_PRIVATE_KEY. GITHUB_TOKEN cannot push commits that touch .github/workflows/, and PRs it opens do not trigger the review checks.
• Claude API federation: vars.REBASE_FEDERATION_RULE_ID, REBASE_ORGANIZATION_ID, REBASE_SERVICE_ACCOUNT_ID, REBASE_WORKSPACE_ID, each falling back to the PR_REVIEW_* variable. The rule must accept a scheduled run's OIDC subject, which a rule written for pull_request events will not.

[github-actions]

PR Review

Reviewed at d21f92c.

This check did not finish, so it has nothing to say about the diff. The run log has the reason.

Test Coverage

Reviewed at d21f92c.

This check did not finish, so it has nothing to say about the diff. The run log has the reason.

[found-it]

Just a note, this will never be PR_REVIEW_FEDERATION_RULE_ID, since REBASE_FEDERATION_RULE_ID is set it will always take precedence. It's not harmful since this workflow isn't triggered on pull_request_review anyways. Just wanted to note that though