implement-spec: step 9 cleanup collides with branch -D guards and with rewritten integration history

## Problem `skills/engineering/implement-spec/SKILL.md` step 9 says only: > 9. Clean up all **implementer subagent** worktrees. It does not say how to remove the implementer branches, or what to do when a deletion is refused. In practice the agent reaches for `git worktree remove … && git branch -D …` as one compound command. That fails in a setup this repo itself recommends: `git-guardrails-claude-code` blocks `git branch -D`, and a deny rule like `Bash(git branch -D:*)` has the same effect. The guard rejects the whole compound command, so even the `git worktree remove` parts never run, and the run ends with every worktree still present. `git branch -d` is not a drop-in replacement either. Once an implementer branch has been merged into the integration branch, the orchestrator often rewrites the integration history: it cherry-picks the commits to drop the merge commits for a single linear PR, or it amends a commit message after code review. After that, the implementer branches are no longer ancestors of the integration branch, and `-d` refuses them. Observed once (two-ticket spec, two worktree implementers, integration history linearised after review): the cleanup command was denied as a whole, and the user had to run it by hand. ## Proposed wording for step 9 ```text 9. Clean up all **implementer subagent** worktrees: remove each with `git worktree remove`, then delete its branch with `git branch -d`. Run each removal as its own command, so a refused deletion doesn't stop the rest. Never force a deletion (`-D`, `--force`). If `-d` refuses a branch because rewritten integration history no longer contains it, confirm that its changes are on the integration branch, then list the branch and the exact command for the user to run. ``` This keeps step 9 compatible with `git-guardrails-claude-code`. The decision to discard an unmerged branch then stays with the user.