buzz-dev-mcp never cleans up its temp folders, 5 GB in two days on one machine

Every time a dev-mcp server starts it drops two folders into the OS temp dir, and it never takes them back out. They just pile up.

I found this the hard way. My C: drive was choking and I went hunting for whatever was eating it. It was Buzz. 21.5 GB across 456 folders. I wiped them clean on August 14. Two days later, same story.

Right now on this machine:

```
104 folders
5.05 GB total
oldest buzz-dev-mcp-ehqhv7 2026-08-15 03:00
newest buzz-dev-mcp-BgkM0X 2026-08-16 12:16
```

That is under two days of normal use. Each shim folder is 97 MB because it carries a full copy of buzz.exe plus rg.exe, tree.exe and the git helpers. Two folders per server start, one shim and one session.

### Where they come from

- `crates/buzz-dev-mcp/src/shim.rs:26` creates the `buzz-dev-mcp-` folder
- `crates/buzz-dev-mcp/src/shell.rs:41` creates the `buzz-dev-mcp-session-` one

Both use `tempfile::TempDir`, so cleanup lives in `Drop`. That is the whole bug. `Drop` only runs on a graceful exit, and these processes get killed instead, so the destructor never fires and the folder is orphaned on the spot. On Windows a hard kill is not catchable at all, so there is nothing to hang cleanup on in the first place.

And there is no backstop. I grepped the tree at `d8281b9` for the prefix and the only hits are those two creation sites plus the CI and Justfile build lines. Nothing anywhere sweeps stale `buzz-dev-mcp-*` folders, not at startup, not ever. Once a folder is orphaned it stays orphaned until a human goes in with a broom.

### Repro

1. Run Buzz with agents that use the dev MCP server
2. Let sessions start and stop through a normal working day
3. Look in your temp dir
4. Enjoy the view

### What I think the fix should be

Do not sweep by age. "Delete anything older than 24 hours" is the obvious move and it is the wrong one, because it will rip the shim out from under a session that is still alive. Mine run for days at a stretch and would lose their binaries and key file mid-flight.

Better move is to write a pid file into each folder at creation, then on startup sweep only the folders whose owning process is gone. That is correct by construction instead of correct by hoping nobody runs long.

### Not a duplicate of

#5781 is git worktree disk usage, different directory and different mechanism. #5849 and #5944 are leaked processes. This one is leaked files. I searched the tracker for temp, tempdir and buzz-dev-mcp and found nothing else covering it.

### Environment

Windows 11 Pro 26200, Buzz Desktop, source read at `d8281b9`.

Happy to write the PR if a maintainer confirms the pid file approach is the direction you want to go.

Start with crates/buzz-dev-mcp/src/shim.rs:26 and crates/buzz-dev-mcp/src/shell.rs:41, then trace how the dev-mcp server starts and exits. Verify the cleanup behavior on Windows, including hard-killed processes and sessions that remain alive for days. Done means orphaned buzz-dev-mcp-* folders are reclaimed without removing folders still owned by running sessions.

Written by the indexing model from the issue text.