[Bug] Windows: 'Not responding' and crash when running more than 3 sessions in parallel (32GB RAM)

Reported via Discord: https://discord.com/channels/1492228674081263786/1492228675272315163/1522171200975929387

> I am using the Orca app on Windows system (32GB RAM). When I try to run more than 3 sessions parallelly across different projects, it goes to "Not responding" and crashes. Anyone else facing this? Is there a way to fix this?

Same symptom family as #7017 (freeze/crash under multi-agent load; that issue's Windows/WSL comment describes terminal lag, then app-wide sluggishness, then a crash).

Suspected contributing mechanisms, in rough likelihood order:

- **Renderer main-thread saturation from concurrent terminal output.** All sessions in a window share one renderer; the output scheduler could feed xterm up to 256 KB/ms, keeping the thread pinned in parse slices. The threshold-like onset ("more than 3 sessions") fits shared-thread saturation. This part is targeted by the drain-pacing change in #7139.
- **Main-process load scaling with project count** (git status polling, PTY/IPC, file watchers). "Not responding" on Windows usually indicates the main process message pump is blocked. Idle git polling was reduced separately by #7069 (v1.4.117).
- **Memory growth / OOM.** A crash on a 32 GB machine may be memory-driven, like the original #7017 report (140 GB). The drain-pacing change does not reduce memory use.

Triage questions for the reporter:

- Orca version, and are agents running locally, over WSL, or SSH?
- Does the terminal get visibly laggy *before* the whole app stops responding?
- Task Manager: which process balloons — Orca renderer, Orca main, or the agent CLIs?
- Does it recover after stopping agents / closing terminals, or only after restart?
- A screenshot of Orca's Resource Manager while it's degrading, if possible.