chore: update tend workflows (0.2.7 → 0.2.8)

[dormouse-bot]

Regenerates the tend workflows at 0.2.8 (from 0.2.7). Two changes alter how
this repo's automation is controlled; the rest tightens behaviour the bot
already had.

Pausing tend moves from .config/tend.yaml to a repository variable
(max-sixty/tend#1233). Every job's gate becomes
vars.TEND_ENABLED != 'false', and the ~70-line inlined Ruby step that fetched
and parsed enabled: out of the config on every single run is deleted from all
eight workflows — that alone is most of the 813 deleted lines here. We set no
enabled: key today, so nothing changes in practice, but from this version on
the lever is a TEND_ENABLED repository variable set to false, and editing
.config/tend.yaml no longer pauses anything.

Review mentions gain their own workflow, tend-mention-relay.yaml
(max-sixty/tend#1230). A pull_request_review run carries refs/pull/N/merge,
which the tend environment refuses, so that path previously could not reach
the secrets it needed. The relay holds no secret at all: it re-posts the event
as a repository_dispatch that starts tend-mention on main, where all the
judgement already lives. It is a separate file because GitHub lists every job
of a review-event run among the PR's checks — skipped jobs included — so a
relay job inside tend-mention would add a permanently-skipped check to every
PR. Same-repo PRs only; fork PRs keep going through the notifications poll.
It matches the tend-*.yaml glob, so docs/specs/security-ci.md →
"GitHub Actions Policies" already classifies it as agent-managed and
workflow-audit.yaml will classify this commit as a tend regeneration.

Behaviour fixes adopters will notice:

• Conflict resolution merges the base branch it fetched rather than the PR's
  recorded baseRefOid, so a stale record no longer resolves against an
  out-of-date tip (fix(resolve-conflicts): merge the fetched base branch, not the PR's baseRefOid max-sixty/tend#1232).
• The notifications poll counts queued runs when deciding who owns a subject,
  so two runs stop claiming the same thread (fix(notifications): count queued runs when checking who owns a subject max-sixty/tend#1235).
• review-runs converges its live-work red listing before trusting it and
  closes a generated red run against a later green of the same name — fewer
  false CI-failure reports (fix(review-runs): converge the live-work red listing before trusting it max-sixty/tend#1243, fix(review-runs): move the live-work red sweep into a tested script max-sixty/tend#1245,
  fix(review-runs): close a generated red run against a later green of the same name max-sixty/tend#1247).
• Dedup list caps raised to 200 across the skills, so a repo with many open
  issues or PRs no longer silently truncates the list a session dedups against
  (fix(skills): raise the remaining dedup list caps to 200 max-sixty/tend#1239).

Pinned tool versions move with it: astral-sh/setup-uv v10.1.0, uv 0.12.13,
Claude Code 2.1.270, sandbox runtime 0.0.76.

Full comparison: max-sixty/tend@0.2.7...0.2.8

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	4c0b034
Status:	✅  Deploy successful!
Preview URL:	https://4b7776bb.mouseterm.pages.dev
Branch Preview URL:	https://tend-update-workflows.mouseterm.pages.dev

View logs

[dormouse-bot]

Feedback on work in progress, not a merge verdict — mark the PR ready to
request the full review.

This regeneration moves the bot's off switch out of the repository. The
enabled: key in .config/tend.yaml is gone from all eight workflows and
every gate is now vars.TEND_ENABLED, which exists only in GitHub's
repository-variable settings. grep -rn TEND_ENABLED outside
.github/workflows/tend-*.yaml returns nothing, so once this merges there is
no way to find the kill switch for an agent holding a repo + workflow PAT
by reading the repo — the generated if: lines show what the variable does,
not that it is the lever or who is able to set it.

docs/specs/security-ci.md -> "Automated Maintainer (tend)" is where that
belongs; it already states what each secret buys and what stays admin-gated,
and "how to stop it" is the same posture question. One sentence naming the
variable, the unset default (absent resolves to the empty string, which is not
'false', so every job runs), and the access tier that can set it would cover
it. That spec is near its 2500-word budget, so the edit may need
node scripts/spec-lint.mjs --ratchet docs/specs/security-ci.md in the same
commit.

I'm not pushing to a draft branch; this can go in before the PR is marked
ready, or I can add it on request.