Add monthly gh-aw upgrade check to catch version staleness

[AR-May]

Problem

The agentic workflows have been broken three times recently by a stale gh-aw version: #14842, #14870 and #14935. The failure is quiet — it happens in the activation job, so the agent step is skipped and no issues or quarantine PRs are created.

gh-aw ships a minor release every one to two weeks. Every compiled .lock.yml embeds the version that produced it, and at run time the activation job compares that version against the gh-aw compatibility policy:

Policy	Effect
minRecommendedVersion	warns
minimumVersion	fails
blockedVersions	fails

Nothing in this repository moves the version forward, so it drifts until it crosses a failing threshold and someone notices a red run.

This is about to matter more, not less: #14938 restores the Dependabot ignore rule for github/gh-aw-actions/*, which is correct — those pins are compiler-managed and must not be bumped in isolation — but it also means Dependabot will no longer nudge the version at all.

Fix

Enable the check that gh-aw provides for exactly this purpose, via .github/workflows/aw.json:

{
  "auto_upgrade": {
    "cron": "23 5 1 * *"
  }
}

gh aw compile then generates .github/workflows/agentic-auto-upgrade.yml.

What the workflow does

Despite the generated name, it does not upgrade the repository. On each run it:

1. Runs gh aw upgrade against a checkout inside the runner.
2. Diffs the result against a fixed list of upgrade-managed files, chiefly .github/aw/actions-lock.json.
3. Exits quietly when nothing changed.
4. Otherwise discards the work and opens an issue labelled agentic-workflows. Any previous open auto-upgrade issue is closed first, so at most one is ever outstanding.

It never pushes a branch and never opens a PR — permissions: contents: read means it structurally cannot. Applying the upgrade stays a deliberate step: a kitten runs gh aw upgrade --create-pull-request locally, which raises the PR under their own account and therefore gets a full CI run. A PR opened by GITHUB_TOKEN would not trigger workflows, which is the wrong property for a change that regenerates CI workflow files.

Why monthly rather than weekly

The default schedule is weekly. Monthly is a better fit here:

• The signal is level-triggered, not edge-triggered. It reports "an upgrade exists", which stays true until someone acts, and the workflow closes and reopens the issue on every run. A weekly cadence against a monthly response produces three redundant notifications for a state that is already known.
• The enforced minimum version currently trails the latest release by about five months, so acting monthly leaves a wide margin.
• Kitten duty rotates monthly, so this produces exactly one issue per rotation, with a clear owner.

23 5 1 * * is the 1st of each month at 05:23 UTC, early enough in the month not to collide with end-of-month release checklist work.

Verified against the current repository state: running gh aw upgrade today leaves .github/aw/actions-lock.json unchanged, so the workflow correctly reports nothing and stays silent while the repository is current.

What this adds

• .github/workflows/aw.json — the opt-in config. auto_upgrade defaults to false, which is why nothing existed before.
• .github/workflows/agentic-auto-upgrade.yml — generated, do not edit by hand.
• .github/aw/actions-lock.json — gains the github/gh-aw-actions/setup-cli@v0.88.2 SHA pin used by the new workflow.

No existing .lock.yml file changes. Compiled with gh-aw v0.88.2, the same version the current lock files were built with, and the result is idempotent across repeated runs.

Risk

Low. The generated workflow does not run an agent:

• Plain actions/github-script running gh-aw's own script; no LLM engine and no inference cost.
• Uses the default GITHUB_TOKEN; no new secrets.
• permissions: contents: read, issues: write.
• All actions SHA-pinned.
• workflow_dispatch is available for a manual run.

The worst case is one redundant issue per month; the current worst case is silently broken agentic workflows.