chore: update tend workflows (0.2.15 → 0.3.1)

[prql-bot]

Regenerates the nine tend-* workflows with tend 0.3.1, up from 0.2.15. The diff is the action pin plus two new inputs on every job, both set to the value that preserves today's behaviour.

merge: maintainer. max-sixty/tend#1172 adds an opt-in merge: yolo mode that lets the bot merge ordinary PRs itself, under a PR-only branch-protection bypass pinned to the expected head SHA. maintainer is the default and is what the generator emits here, because .config/tend.yaml sets no merge: key — so the bot still cannot merge anything, and this PR grants it no new authority. Adopting yolo later would be a deliberate config change, not a side effect of a regen.

control_plane_owner: "". The CODEOWNER that would gate workflow and .config/tend.yaml changes under yolo. Empty under maintainer, where it has no effect.

tend check is stricter, and that is why a new drift line appeared tonight. max-sixty/tend#1382 extends the branch-protection check from update alone to the whole ref lifecycle — creation, update, deletion — and tightens credential-environment auditing. Tonight's sweep ran the 0.3.1 check and reported branch-protection:main as failing for the first time; the repo's rulesets did not change. That is tracked on #6340, and clearing it needs a repository admin to run tend check --fix.

Smaller upstream fixes that reach this repo's runs: review-runs correction rows now keep each row's author (#1374), the run listing pages to the Actions API ceiling instead of stopping early (#1377), and the CI poll loop is bounded by a sleep budget rather than a pass count (#1376). The pinned Claude Code CLI moves to 2.1.280.

Full comparison: 0.2.15...0.3.1. Release mechanics, lockfile bumps and tend-internal work are omitted above.

The generated files are the generator's own output. Re-running uvx tend@0.3.1 init against this branch reproduces the nine workflows byte-for-byte, so the diff is the generator's and nothing hand-edited slipped in.

One hand-written file changes alongside them: the comment in .github/actions/tend-setup/action.yaml that records the sandbox_setup: deprecation named 0.2.15 as the version accepting the key, which this bump makes stale. Running the generator at 0.2.15 and 0.3.1 gives an unchanged deprecation warning and the same combined run: step, so the note now names 0.3.1 and the migration it points to is still a follow-up.

[prql-bot]

#6363 regenerates these same nine workflows at 0.3.1 — including the same merge: maintainer and control_plane_owner: "" inputs — while also switching the harness from claude to codex. The two PRs therefore collide on every line this one touches, and whichever lands second needs a fresh uvx tend init rather than a textual merge. #6363 is a draft, so nothing here is blocked on it, but these aren't two independent bumps: taking both is a decision about which harness runs tend.

Separately, the note in .github/actions/tend-setup/action.yaml that records the sandbox_setup: deprecation pins its claim to a specific version — ".config/tend.yaml still uses the deprecated sandbox_setup: key, which 0.2.15 accepts with a warning and emits as a run: step after this composite". Once this merges the repo pins 0.3.1, so the note stops answering the question it exists to answer: is the key still accepted at the version we run? I ran the generator at both versions against this branch's config — the deprecation warning is unchanged and both emit the same combined run: step — so the answer is still yes, and only the version needs updating. Pushing that one-line change to this branch.