source-control: merge phase says 'worktree cleanup' but never removes; move removal to a periodic sweep #6441

Problem

Sessions remove merged PR worktrees inline and fight permission prompts to do it:

• Every worktree carries a session claim lock. worktree-claim.sh stale refuses to call a lock stale while the owning transcript changed in the last 120 minutes.
• Overriding the lock with git worktree unlock was denied by the auto-mode classifier ("Interfere With Workloads"), even with the user's approval given in chat. The user had to run the unlocks by hand.
• Observed 2026-10-05 on four merged PRs (test(review): let the fanout re-review eval cases load the skill and drop Skill-call graders #6411 fix(planning): bind wayfind SDK exclusion grader to one clause #6415 fix(wizard): refuse already-exported variables as .env keys #6418 fix(wizard): confirm before writing ENV_FILE into git metadata #6427): two subagent rounds, two user prompts, and one hand-run command, all to remove four clean worktrees.

Cause (corrected after investigation)

No skill instructs inline removal. /source-control:pull-request merge §4.3 (skills/pull-request/reference/merge.md) either reuses the worktree for the next branch or leaves it and releases this session's lock. It never runs git worktree remove. But SKILL.md:68 and templates/checklist.md:13,20 describe the phase as "worktree cleanup", which reads as an instruction to remove.

Those four PRs merged through auto-merge, so §4.3 never ran, their locks were never released, and a session handoff carried "clean up merged PR worktrees" forward on its own judgment. No session-flow instruction drives that.

Decided (2026-10-05)

• No new userConfig key: with no removal step in the merge phase, a key would gate nothing.
• Fix the wording: the merge phase "transitions" the worktree (reuse it, or release the lock) and never removes it. Removing merged worktrees belongs to /source-control:worktree cleanup.
• Removal moves to a periodic sweep running /source-control:worktree cleanup. By then the locks are past the 120-minute window, so stale passes and no unlock override is needed.

Open question

Where the periodic sweep runs. A cloud routine (/schedule) cannot reach local worktrees, so it needs a local runner: a standing /loop session or an OS-scheduled headless run. Unverified: whether an unattended git worktree remove of a stale-claimed worktree passes the auto-mode classifier.