Long lived git worktrees

[yringler]

What are you proposing?

Allow manual control over when worktree is deleted.

If I manually create something, I expect to be in charge of its full lifecycle - if I created it, it should remain in the state I set until I change that state myself. Currently, that is not the case: if zed sees that all threads referencing a worktree were archived, it removes the worktree.

Why does this matter?

Having long lived worktrees means that I always have an isolated worktree ready. The repo is cloned, and build dependencies are already in place — node_modules, .venv, build caches, compiled binaries. Recreating these is expensive (minutes to tens of minutes depending on the project), so auto-deletion isn't just losing a directory; it's losing the warm state.

I happen to name my worktrees after my siblings - it makes it easier to keep track of who's doing what when I have a few different agents adding different features / fixing different bugs.

Beyond the workflow cost, there's a UX principle at stake: ownership. There are two distinct models for how a worktree can come into existence:

1. User-created - I explicitly created the worktree through the UI. I named it, I know it exists, I'm tracking it. This is what zed currently supports, but without the ownership guarantee.
2. Zed-created - hypothetically: zed created the worktree on my behalf as part of some abstracted flow (if "Create thread in worktree" were an option in the thread creation UI, with the worktree's existence and name managed behind the scenes).

For case 2, automatic cleanup is expected behavior. I didn't create it directly, so zed handling its lifecycle wouldn't surprise me.

For case 1, automatic cleanup violates the ownership contract. If I created it manually, I should remove it manually — without zed removing it for me based on the state of unrelated objects (threads).

Possible approach

Change the default: manually-created worktrees are never auto-removed. If zed-managed worktrees become a thing (from an abstracted flow like the hypothetical above), those would be subject to automatic cleanup.

A less invasive alternative is a setting to opt out of auto-removal for manually-created worktrees, preserving current behavior as the default.

Related to #55434

[karlismelderis-mckinsey]

Please make this happen. I was burned by this and now I have a worktrees that ZED doesn't see and I cannot reuse