Desktop app spawns ~17 git processes per second continuously (Windows), amplifying a kernel pool leak into ~6 GB/day

## Summary

On Windows, the desktop app continuously spawns `git.exe` at a very high rate — measured **15–20 process starts per second, sustained**, each with its own `conhost.exe`. That is ~2 million short-lived processes per day from a single open app.

This is wasteful on its own, but on this machine it also acts as a ~25× amplifier for a separate kernel-level defect (Windows Defender's `WdFilter.sys` leaks one process-object reference per created process), turning a negligible leak into **~6 GB of non-paged kernel pool per day**, after which the machine can no longer shut down cleanly and has to be power-cycled.

## Measurements

Process starts captured with WMI `Win32_ProcessStartTrace` (ordinary process sampling misses them — these processes live under 40 ms):

```
starts in 10 s: 297
git.exe 191
conhost.exe 97
```

Parent attribution, same trace:

```
git spawned by: claude (pid 19804) 97 times in 8 s
```

The parent is the app's node utility process:

```
claude.exe --type=utility --utility-sub-type=node.mojom.NodeService
```

The command being run repeatedly is a plain `git` invocation against the open project directory.

## What does NOT change the rate

Each of these was measured before/after, 10-second windows:

| action | git starts / 10 s |
|---|---|
| baseline | 198 |
| archived every session except the current one | 198 |
| restarted the desktop app completely | 173 |
| closed the diff / changes panel | 152 |

So it is not a runaway loop accumulated over a long session, not per-session, and not tied to the diff panel being open. The app also keeps a change indicator on its icon, which may be what keeps the polling alive regardless of the panel.

## Environment

- Windows 10 22H2 (10.0.19045), 47 GB RAM
- Claude Code desktop app 1.52386.6
- One project open (a Go monorepo), git repo on a local NTFS disk

## Why it matters beyond CPU

Every created process on this machine leaks its `EPROCESS` and token in the kernel pool (confirmed with LiveKD + object reference tracing: `gflags -ko -t Proc`, then `!obtrace` on a terminated process object — the outstanding reference is taken by `WdFilter.sys` via `PsLookupProcessByProcessId`). That is Microsoft's bug, not this app's. But the app's polling rate is what makes it fatal:

- kernel pool with the app open, idle: **+300–700 MB per hour**
- a full 13-minute CI run of the project: +206 MB (i.e. less than an hour of the app sitting idle)
- non-paged pool reaches the danger zone (3–4 GB) within a working day, and the machine then fails to reboot from the OS

## Suggested fix

Poll git on an event (file-system watch / focus change) or at a human interval (seconds, not 60 ms), and reuse a single long-lived git process where possible. Even a 1-second interval would be a 20× reduction.

Trace the Windows desktop app's Node utility process and the plain git invocation against the open project directory; begin by identifying what keeps the change indicator polling while the app is idle. Done means the sustained 15–20 git starts per second is replaced by event-based or human-interval polling, verified with Win32_ProcessStartTrace.

Written by the indexing model from the issue text.