[Bug] 1.0.49 regression: TUI rendering lag inside tmux on mintty/Cygwin

### Describe the bug

## Summary

The TUI in copilot CLI 1.0.49 renders with severe lag (bursts then freezes, spinner stutter, "stuck until keypress") when run inside a tmux pane on Cygwin/Windows. Versions **1.0.43 and 1.0.48 do not have this problem**. The regression seems to have been introduced in 1.0.49.

The problem disappears when copilot is run directly in mintty without tmux, so this is specific to copilot's interaction with tmux's pane render pipeline.

## Environment

- Windows 11
- Cygwin 3.6.9 (mintty 3.8.2)
- tmux next-3.4 (Cygwin package, ~Jan 2024 snapshot of post-3.3a)
- Also reproduces on tmux 3.6b built from upstream

## Reproduction

1. From a Cygwin mintty inside a tmux session, launch copilot:
2. Send a couple of prompts that produce streaming output (e.g. "list 1 to 100, one per line").
3. Observe: output arrives in bursts, the spinner stutters, the cursor occasionally freezes until a keypress.

## Bisection result

Same machine, same tmux pane, same prompt:

| Version | Behavior |
|---|---|
| 1.0.43 | smooth |
| 1.0.48 | smooth |
| 1.0.49 | laggy (all symptoms above) |

## Byte-stream analysis

Captured copilot's pty output via `tmux pipe-pane -O` while it produced ~30KB over ~7 seconds:

- 232 distinct chunks; mean chunk size 116 bytes; chunk-rate ~31/sec
- 87 BSU/ESU pairs (`ESC[?2026h ... ESC[?2026l`) emitted — but **all 87 are empty**: zero bytes between the BSU and the matching ESU. Confirmed by regex extraction:
```
unique sync frame contents: 1 (the empty bytestring b'')
```
- The actual screen-update content (cursor movements, color codes, text) arrives in **separate, unwrapped chunks** afterward, with inter-chunk gaps up to 226ms (p95: 102ms).

In other words: copilot announces a synchronized update (`BSU` then `ESU` immediately), then writes the real frame content in subsequent unframed chunks. Tmux faithfully renders each unframed chunk independently. The mode-2026 sync mechanism is being emitted but is not actually wrapping any content.

For comparison, equivalent bash and PowerShell output through the same tmux pane is smooth. Those producers send append-only line-oriented output and don't trigger this rendering pattern.

## Workaround

Downgrade to 1.0.48

### Affected version

_No response_

### Steps to reproduce the behavior

_No response_

### Expected behavior

_No response_

### Additional context

_No response_