[High severity] 1.0.60 WSL2 regression: CLI MainThread spins at ~215% CPU while idle, TUI output frozen until restart (regression of #2208)

## Severity / Impact

- **Severity: High** — the TUI becomes effectively unusable; live output (assistant reasoning and streamed text) never paints until the CLI is restarted.
- **Impact: High** — reproduces on every fresh session, immediately after a clean machine reboot, with default usage. Workflow-blocking.
- **Regression of previously-fixed [#2208](https://github.com/github/copilot-cli/issues/2208)** ("copilot cli in wsl spinning on the cpu with an unresponsive tui", reported on 1.0.10, closed as completed 2026-04-07). The same class of bug is back in 1.0.60.

### Describe the bug

On **1.0.60** under **WSL2 (Ubuntu-22.04)**, the CLI process spins at ~**215–220% CPU continuously, even while idle** (between turns, with no prompt running). The render/event loop is CPU-starved, so after I submit a prompt the assistant's reasoning and streamed output **do not appear on screen** — the UI looks frozen. The work is actually completing in the background (events are written to `events.jsonl`); **only restarting the CLI makes the result appear**.

### Affected version

`GitHub Copilot CLI 1.0.60` (latest; `dist-tags.latest = 1.0.60`).

### Environment

- WSL2, Ubuntu-22.04, x86_64
- TERM=xterm-256color, not inside tmux/screen (WSL relay PTY)
- 31 GiB RAM (not memory-constrained), load average ~2–4

### CPU / thread profile (the signature)

Measured on a **freshly rebooted** machine, fresh process, **idle** (no active turn):

```
PID 73114 total %CPU = 215–221 (cumulative since start, i.e. continuous spin)
MainThread ~98% (full core)
V8Worker ~30% x4 (GC/JIT helper threads thrashing)
tokio-rt-worker ~0%
/proc//task//wchan = 0 (RUNNING, not blocked on I/O — confirmed busy-spin)
```

On **1.0.59** (same machine, same session, launched via `--prefer-version 1.0.59`) the identical session is healthy: MainThread idle at ~0%, no V8Worker spinning, cumulative %CPU actually *decreases* over time (proving near-idle). **Downgrading to 1.0.59 fully resolves it.**

### Steps to reproduce

1. On WSL2 (Ubuntu-22.04), run `copilot` on 1.0.60 (interactive TUI).
2. Submit any prompt that streams reasoning/output.
3. Observe: output does not render live; `top` shows the CLI MainThread pegged at ~98% (≈215% total) even when idle between turns.
4. Restart the CLI — the previously "missing" output now appears.

### Expected behavior

Idle CPU near 0%. Streamed reasoning and assistant output render live in the timeline without requiring a restart.

### What was ruled out (so it's clearly a CLI regression, not user config)

All of the following were tested and did **not** fix it on 1.0.60; the spin persisted on a cold-booted machine with a fresh process:

- `/compact` (timeline reduced to ~120 KB)
- Trimming MCP servers (74 → 30 child processes)
- Removing a large custom-agent data folder from `~/.copilot/agents/` (stopped a 1,139-file scan, but unrelated to the spin)
- Lowering reasoning effort `high → medium`
- Lowering `logLevel` `all → info`
- No background subagents/sidekicks active (`GITHUB_CONTEXT_SIDEKICK_AGENT=false`)
- Bundled Node runtime (not the system/nvm Node)

The only change that resolves it is **version 1.0.60 → 1.0.59**, which strongly implicates a render/event-loop regression introduced in 1.0.60.

### Additional context

- Prior fixed issue (same symptom class): #2208.
- The 1.0.60 changelog adds a new max reasoning-effort tier and several render-related changes; a busy-loop in the streaming render/poll path is the most likely area.
- Happy to capture a CPU/devtools trace if useful (as was attached to #2208).