Automatically clean up (close or delete) worktree after background agent changes are applied

[bamurtaugh]

We've gotten user feedback about worktrees from background agents that includes:

Also, is the expectation that we'll have a local my_project.worktrees that hangs around after the agent does its work? Or does this get cleaned up eventually?

I think either closing or deleting worktrees after a user has applied their changes, and/or archived a background agent session, could be helpful?

If we'd prefer to track as part of #282043 (comment) or another issue, definitely please feel free to close!

[apdarr]

I'm wondering if something like this is possible:

• If the created .worktree directory only contains a single worktree directory created by the @cli background agent, it's safe to delete the .worktree after merge.
• Otherwise, the .worktree is preserved in cases where the developer uses worktrees outside of background agents or has other background agent sessions not merged.

Just thinking of ways in which this cleanup process could avoid conflicts with a developer's existing worktree flow.

Similarly, to better help identify user-created worktrees and background agent-created worktrees should we prepend copilot-* (or some other identifier) to the agent-created worktrees? In VS Code 1.107.0, the background agent created a worktree with this name: worktree-2025-12-15T14-09-08. I believe copilot-worktree-2025-12-15T14-09-08 would add clarity to the mechanics involved.