Window live renderer transcript/runtime state by bytes, not only initial history count #375

Problem

The renderer/runtime investigation found that initial transcript history is capped, but live SessionRuntime.entries append can grow without a byte/window cap while many agents remain open or detached in Dispatch. This is likely secondary to the main-process OOM, but can amplify memory during orchestration-heavy runs and large MCP/tool outputs.

Findings

• Initial history and older pages are capped, but live JSONL appends grow runtime.entries without an obvious byte/window cap.
• Semantic state keeps full blocks for current turn and capped history/logs, but those caps are by count, not bytes.
• Feed-debug runtime is count-capped, but raw semantic payloads can be large.
• Mounted feed rows intentionally never unmount once mounted; large code blocks can retain exact source strings and Monaco models until pane close.

Proposed Fix

• Add renderer memory instrumentation per session: entry count/bytes, semantic block bytes, feed-debug bytes, tool-map refs, code block registry, Monaco model count.
• Introduce a live transcript window by count and bytes, preserving total counts/markers and load-on-scroll behavior.
• When trimming, rebuild/prune tool maps and UUID bookkeeping so old block references are not retained.
• Compact archived semantic state after durable JSONL ownership arrives; keep full current turn but summarize/cap history/log payloads.
• Store runtime feed-debug mostly as summaries/scalars unless full raw debug capture is explicitly requested.
• Consider hibernation for background dispatch/orchestration agents: keep metadata/status, drop runtime bodies, reload capped history on focus.

Acceptance

• Long live transcripts and many background agents do not retain unbounded renderer entries.
• Tool maps/semantic/debug sidecars do not keep trimmed entries alive.
• Renderer memory instrumentation can identify the top per-session retained runtime categories.

Related: #327, #365, #373