chore: update tend workflows (0.1.14 → 0.1.15)

[prql-bot]

Automated nightly regeneration of tend's workflow files (uvx tend@latest init), picking up 85 upstream commits.

tend version: 0.1.14 → 0.1.15

Notable changes

• tend-review no longer cancels itself on a push. cancel-in-progress flips to false and a new inlined pre-check gates the queued run: the live session folds the push in and stamps each commit it examined with a tend-review/<pr> commit status, so the replacement run exits without booting an agent when HEAD is already covered (feat(review): queue pushes behind an examined-HEAD gate instead of cancelling max-sixty/tend#903, fix(running-in-ci): batch pushes so the author doesn't cancel its own reviewer max-sixty/tend#868). This is the bulk of the diff in tend-review.yaml.
• tend-mention's self-loop guard covers rate-limit pauses. The skip now matches tend-rate-limit alongside tend-outage, so a rate-limit pause notice can't re-trigger mention in a loop; a maintainer can approve past the spike limit to resume (feat(rate-limit): let a maintainer approve past the spike limit max-sixty/tend#874). It also skips the synthetic reply container the bot's own inline reply creates (fix(mention): skip the synthetic reply container the bot's own inline reply creates max-sixty/tend#849).
• Inline-comment @-mentions are no longer missed past the first page. The review-comment fetch in tend-mention switched to one object per line so --paginate concatenates pages instead of reducing within each one.
• tend-notifications pre-check is now self-contained and parameterized — the bot login comes in as BOT_NAME rather than being hardcoded mid-script, and the step carries its own env block.
• Skill fixes that don't show in the diff but change run behavior: the CI-monitoring poll cap is terminal rather than falling through (fix(running-in-ci): make the CI-monitor poll cap terminal max-sixty/tend#876), a failed GitHub-status probe no longer reads as "no incident" (fix(running-in-ci): don't let a failed status probe read as no incident max-sixty/tend#913), and tend check reports an unreadable ruleset bypass list as unknown instead of ungated (check: report an unreadable ruleset bypass list as unknown, not ungated max-sixty/tend#825).

Full comparison: max-sixty/tend@0.1.14...0.1.15

[prql-bot]

Regeneration looks faithful and the new gate mechanism checks out. One observation, plus verification notes below — a later session on this thread starts cold, so the thread is the only durable record of what was actually checked.

tend-review now queues instead of cancelling, with no cap on how long it can queue. cancel-in-progress flips to false, so a push mid-review no longer kills the running session — the replacement run waits on the per-PR concurrency group instead. That's the intended design, and the new gate makes the wait cheap when the live session stamps HEAD. What's missing is a floor under the pathological case: no tend workflow declares timeout-minutes, so a session that wedges rather than ends holds the group for GitHub's 360-minute default, and the queued review waits behind it. Under 0.1.14 the next push cancelled a wedged run outright. I haven't observed a wedge — of the last 40 completed tend-review runs on this repo the longest was 41 minutes — so this is a tail risk, not a live bug. The fix belongs upstream as timeout-minutes: on the generated review job; these files carry "Do not edit this file directly", so there's nothing to suggest inline here.

Nothing else actionable. CI is green, including check-ok-to-merge.

What I verified (notes for a cold follow-up)

The new gate is only safe if three things hold. All three check out:

• The stamp can actually be written. The gate skips when a tend-review/<pr> commit status sits on the live HEAD, which the review skill POSTs using TEND_BOT_TOKEN. That token is a classic PAT carrying repo, which subsumes repo:status — so the stamp lands. Worth recording because the failure mode is silent: with a fine-grained PAT lacking "Commit statuses: write", the stamp would never appear, every queued run would boot a full agent, and combined with cancel-in-progress: false that is worse than 0.1.14 — duplicate reviews replacing cancellations rather than avoiding them.
• The stamp cannot deadlock the CI poll loop. Upstream writes it as -f state=success (tend 0.1.15, review skill, "Stamp examined HEADs, then re-check for a new push"), never pending, so it reads terminal in statusCheckRollup and the pending() helper ignores it.
• The regeneration is faithful, not hand-edited. The entire gate step in .github/workflows/tend-review.yaml is byte-identical to the generator's own regtest fixture at 0.1.15 (generator/tests/_regtest_outputs/test_generate.test_workflow_with_local_setup_regtest[review].out).

Two candidates I chased and dismissed:

• The issues arm of tend-mention's verify condition has no tend-outage / tend-rate-limit label guard, while the issue_comment arm one line below just gained one. Not a gap: the only issues trigger is types: [edited], and both health flows (enrich-tend-outage-issues.sh, rate-limit-preflight.sh) append with gh issue comment rather than editing the body — so that arm is reachable only by a human edit, which should summon the bot.
• gh api --jq '.[] | {body, in_reply_to_id}' does emit one compact object per line, and the object construction normalizes an absent in_reply_to_id to null, so the new paginated inline-comment scan behaves exactly as its comment claims. Confirmed against the live API.

One note the PR description undersells: the Restore local setup actions for POST cleanup steps matter more on this repo than they might elsewhere. PRQL currently has two open PRs modifying .github/actions/tend-setup (#6177, #6144), and tend-review's second checkout runs with clean: false over the base tree — so on those PRs the composite action's file is the PR's version by the time GitHub re-reads it at job cleanup. The restore step puts the base version back.

[prql-bot]

Filed the one observation from my review upstream as max-sixty/tend#962 — generated jobs carry no timeout-minutes, so with cancel-in-progress: false a review run that wedges in a pre-agent step (outside the supervisor's timeout_seconds window) holds the per-PR concurrency group until GitHub's 360-minute job cap. Confirmed zero timeout-minutes across all seven generator templates on tend main and all eight generated tend-*.yaml here. Still a tail risk, not a live bug: longest completed tend-review in the last 100 runs is 45 minutes on this repo.

Nothing to change in this PR — these files are generated and the fix belongs in the template. CI is green; ready for a maintainer to merge.