[Performance] UI lags minutes behind actual file writes for ~800 line files

Describe the bug

When writing long files in Kimi CLI v1.30, the UI refresh progressively slows down during write operations, lagging minutes to tens of minutes behind actual disk completion. The file content is already fully written to disk (verified by opening in external editors), but the CLI UI continues to slowly refresh, creating severe workflow disruption.

To Reproduce

Steps to reproduce the behavior:

1. Run Kimi CLI v1.30 on Ubuntu 24.04
2. Request generation of a file ~800 lines (code or documentation)
3. Observe the UI write progress indicator
4. During the "slow refresh" phase, open the target file in an external editor (e.g., VS Code, vim, cat)
5. Observe: File is complete on disk while CLI UI continues to lag for minutes to tens of minutes

Expected behavior

UI should reflect write progress in near real-time, with seconds of delay at most—not minutes.

Actual behavior

Environment

Kimi CLI: 1.30
OS: Ubuntu 24.04
Modes affected: ACP, Web

Severity

High — This makes long file operations practically unusable, as users cannot reliably determine when the operation is actually complete.

Additional context

• This is clearly a UI rendering/buffering bottleneck, not a disk I/O issue
• The delay scales with file length (shorter files less affected)
• No visible error messages or crashes—just extreme UI slowness

https://github.com/user-attachments/assets/bf09d864-dd88-4b1c-b99c-4b5beae7abe8

Reproduce the lag with Kimi CLI v1.30 on Ubuntu 24.04 by generating an approximately 800-line file, testing both ACP and Web modes. Compare the UI progress with the file observed externally in VS Code, vim, or cat. Done means long writes complete with UI delay of seconds rather than minutes, without regressions for code or documentation files.