Cron auto-merge — close the unattended loop

PR #1600 sat stuck because the cron-opened branch was BEHIND main and required gh pr update-branch + manual merge. This PR makes the cron set --auto on the PR it creates, so the rebase + merge happen automatically.

The problem the cron has after the M130 saga

  1. 14:00 UTC cron checks out main, runs the pipeline.
  2. peter-evans opens a PR from chore/cc-snapshot-<run_id>.
  3. By the time CI runs against the PR, OTHER PRs may have merged to main → snapshot PR is BEHIND.
  4. Branch protection has strict: true → PR cannot merge until rebased.
  5. Without a human, the PR sits open forever. Tomorrow's cron creates ANOTHER stuck PR. They pile up.

This is exactly what happened to PR #1600 today — until I ran gh pr update-branch 1600 --rebase by hand.

Fix

- name: Open snapshot PR
  id: cpr                                     # ← capture output
  if: success() && steps.changes.outputs.has_changes == 'true'
  uses: peter-evans/create-pull-request@...
  with:
    ...

- name: Enable auto-merge on snapshot PR     # ← NEW
  if: success() && steps.cpr.outputs.pull-request-number
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    gh pr merge "${{ steps.cpr.outputs.pull-request-number }}" \
      --repo "${{ github.repository }}" \
      --auto \
      --squash \
      --delete-branch

gh pr merge --auto queues the merge for when required checks pass and triggers an automatic rebase when the PR is BEHIND. No human action needed.

Why this is safe

Verification path

  1. This PR merges.
  2. Tomorrow's cron at 14:00 UTC runs.
  3. Auto-PR opens; auto-merge enabled.
  4. If main hasn't moved → CI passes → auto-merge fires immediately.
  5. If main HAS moved (e.g., another PR merged in the same minute) → branch auto-rebases → CI re-runs → merges.
  6. No human ever touches it.