chore: update tend workflows (0.2.13 → 0.2.15)

[dormouse-bot]

Regenerates the nine tend-*.yaml workflows at tend 0.2.15, up from 0.2.13. The 0.1.19 security floor in docs/specs/security-ci.md is unaffected.

How the agent is isolated changed. The agent now runs in a hardened systemd unit rather than Anthropic Sandbox Runtime (max-sixty/tend#1354), and it sees the job's own checkout and home through a copy-on-write view instead of a separate clone (max-sixty/tend#1346). That deprecates sandbox_setup, sandbox_path, and sandbox_env — the agent inherits the job's environment (max-sixty/tend#1355). This repo's .config/tend.yaml sets none of the three, so there is nothing to migrate; the tend-review comment about the disposable clone is reworded in this diff to match. Teardown now waits for the killed sandbox UID to leave the process table (max-sixty/tend#1352).

Review behavior is tighter on the bot's own PRs. A follow-up review is scoped to what was pushed while keeping the whole PR in view (max-sixty/tend#1368), and each further fix round on a PR with no human author has to clear a higher bar (max-sixty/tend#1366) — fewer repeat edit-and-push rounds on PRs like this one. Review bodies now open with a finding rather than restating where GitHub shows the verdict (max-sixty/tend#1362).

One change is visible in the diff itself: tend-mention computes its queue delay before checkout and setup: (max-sixty/tend#1365), so the number it reports is the wait for the job to start rather than that wait plus its own setup time.

Also in range: review-runs counts a re-run's failed attempt in its census (max-sixty/tend#1337), and tend check now requires a restrict-updates ruleset and pins AGENTS.override.md alongside the other instruction paths (max-sixty/tend#1367) — this repo already satisfies the ruleset requirement, which tend check reports as branch-protection:main PASS.

One spec follows the isolation change. docs/specs/security-ci.md described the attacker-controlled PR tree as living in the harness's own disposable clone; with the copy-on-write view there is no separate clone, so that sentence now names the view. The Must revert those paths rule and the 0.1.19 floor it backs are untouched — restore-sensitive-config.sh still pins the instruction pathspecs before the agent starts. The rationale's note of the version the workflows run is refreshed to 0.2.15 in the same commit.

Full comparison: max-sixty/tend@0.2.13...0.2.15.

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

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

View logs

[dormouse-bot]

docs/specs/security-ci.md → "Instruction files are part of that surface." still says the attacker-controlled PR tree "exists only in the harness's own disposable clone". At 0.2.15 there is no separate clone: shared/steps/event_checkout.py moves the job's own checkout to the event's topology inside the sandbox, and create-runtime-root.sh places "the view's upper layer" under the per-run runtime root — so the PR tree exists only in the agent's copy-on-write view. This diff reworded that same mechanism in tend-review.yaml's comment and left the spec describing the old one, which is what AGENTS.md → "Specs" ("When code covered by a spec changes, change the spec") covers.

The rule the paragraph carries is unaffected — restore-sensitive-config.sh still pins the instruction pathspecs before the agent starts, so the 0.1.19 floor stands. Only the mechanism sentence is stale. I'm pushing that reword, along with the 0.2.13 version note in security-ci.rationale.md that this commit falsifies.

Evidence the regeneration itself is clean

All nine files reproduce byte-for-byte from uvx tend@0.2.15 init against this repo's .config/tend.yaml (and leave .github/actionlint.yaml unchanged) — the condition workflow-audit.yaml's regen classifier checks. No 0.2.13 reference survives anywhere under .github/, and both setup-uv consumers moved to v10.2.0 together. The tend-mention step reorder is safe: the delay step reads only github.event.*, needs.verify.outputs.ts, and date, and its steps.delay.outputs.seconds consumer is still downstream.