[WS8] Surgical TUI performance improvements to upstream OpenCode TUI

[randomm]

Parent: #158

Context

After evaluating alternatives:

• ❌ oclite — abandoned (too much maintenance)
• ❌ CodeNomad — GUI, not terminal
• ❌ opencode web — trialed, not a great experience
• ❌ Custom thin client — unnecessary effort

Decision: Use upstream's TUI but apply surgical performance fixes.

The upstream TUI has documented severe performance issues:

• High CPU usage (100% single core) during TUI rendering anomalyco/opencode#11119: 100% CPU on single core even when idle (futex busy-loop)
• [Bug]Deep clone of entire message history causes 30+ second delay with 200 messages anomalyco/opencode#10187: 30+ second delay at 200 messages (deep clone of entire history per iteration)
• Add configurable scrollback/message limit to reduce TUI lag anomalyco/opencode#9930: No configurable scrollback limit (PR feat: configurable message and session limits (resolves #4918) anomalyco/opencode#4919 closed unmerged)
• Slow perceived response time due to excessive storage writes during streaming anomalyco/opencode#11329: Hundreds of file writes/sec during streaming
• 🐛 Issue: opencode memory usage keeps growing over time anomalyco/opencode#11399, memory leak anomalyco/opencode#7046, opencode eating 70gb of memory? anomalyco/opencode#5363: Memory leaks growing to 10–70GB

Our specific pain points:

• 84MB binary (bloat)
• Sluggish in long sessions (100+ subagent panes)
• Too many bells and whistles

Approach

Make minimal, focused changes to the upstream TUI that:

1. Fix the worst performance issues
2. Are small enough to maintain across upstream syncs (like the rg tool patch)
3. Could potentially be contributed upstream

Scope Definition (needs collaboration)

To investigate and discuss:

• Which upstream TUI perf issues are fixable with small patches?
• Can we add a scrollback limit / message virtualization with minimal code?
• Can we disable expensive features (file watchers, animations) via config?
• Binary size reduction — can we tree-shake unused features?
• What's the minimum viable change for "not sluggish at 100+ panes"?

Constraints

• Changes must be surgical — under 50 lines per file ideally
• Must be maintainable with rebase-on-sync (like rg tool)
• No structural refactoring of upstream TUI code
• Prefer config flags over code changes where possible

Status: NEEDS SCOPING

This issue requires hands-on investigation with project owner to define specific changes. The upstream issue tracker has analysis of root causes that can guide targeted fixes.

References

• Upstream High CPU usage (100% single core) during TUI rendering anomalyco/opencode#11119: CPU idle loop
• Upstream [Bug]Deep clone of entire message history causes 30+ second delay with 200 messages anomalyco/opencode#10187: Deep clone per iteration
• Upstream Add configurable scrollback/message limit to reduce TUI lag anomalyco/opencode#9930 / PR feat: configurable message and session limits (resolves #4918) anomalyco/opencode#4919: Scrollback limits
• Upstream Slow perceived response time due to excessive storage writes during streaming anomalyco/opencode#11329: Excessive file writes
• Upstream 🐛 Issue: opencode memory usage keeps growing over time anomalyco/opencode#11399, memory leak anomalyco/opencode#7046, opencode eating 70gb of memory? anomalyco/opencode#5363: Memory leaks