backlog-burndown: nothing removes a standalone clone after its group merges #1301

backlog-burndown "Cleanup Is the Orchestrator's" says the whole post-merge procedure moves to the orchestrator and that "It covers every group that is done with its tree." A group that worked out of a standalone clone is not covered, and nothing else removes the clone.

repo-worktree allows a standalone clone as the fallback when the worktree path is unavailable or denied, and its own cleanup requires "Remove temporary standalone clones ... Remove the exact <temporary-root>/<Repo>-<task-slug> path after confirming it is clean." That clone is invisible to git worktree list, lives outside the repository, and nothing in backlog-burndown requires a worker to report its path to the orchestrator. So a group that merged normally out of a standalone clone leaves the clone behind, and no seat holds what is needed to remove it: the worker is gone, and the orchestrator was never told where it was.

The minimum fix is to have the worker brief require the checkout path back, the way it already requires the branch name, so the orchestrator's cleanup step has something to act on. Whether the orchestrator should remove a clone at all is a separate question, given that reaching into another task's checkout is what GOVERNANCE.md "Repository Boundaries and Write Safety" bounds.

This is distinct from #1293, which is about reading a standalone clone's claim during verification, and from the work-loss case now handled in the skill, where an unpushed standalone-clone group stops for the maintainer. This one is the cleanup step for a group that finished successfully.

A second, smaller item in the same subsection: "verifying the merged branch's tip against the pull request's headRefOid before git push origin --delete" has two inaccuracies against drive-pr step 4, the procedure it cites.

• The command as written fails: git push origin --delete with no ref is fatal: --delete doesn't make sense without any refs. The real form is git push origin --delete -- "<branch>", after git ls-remote --heads --exit-code -- origin "refs/heads/<branch>".
• "the merged branch's tip" invites reading the check as against the merge result, which after a squash is a new commit that can never equal headRefOid. That is the same trap the next paragraph of this subsection warns about, so the phrasing works against its own neighbour.

Raised by the local-strict-review carried-content passes on the pull request that added this skill, and deferred there under that skill's own review-round budget.