Reduce default terminal scrollback from 2500 lines

[gregpriday]

Summary

The default terminal scrollback of 2500 lines creates unnecessary memory pressure in Canopy's core use case — running many concurrent agent panels. At 2500 lines per agent terminal, 20 open agents consume ~75MB of xterm.js buffer memory before any output is even rendered.

Problem Statement

Each xterm.js terminal instance pre-allocates its full scrollback buffer regardless of actual content. At 120 columns and 2500 lines, this is approximately 3.8MB per terminal (2500 × 120 cols × 12 bytes/cell + 64 bytes/line overhead). Agent terminals are subject to the full base scrollback (multiplier 1.0), not the reduced rate applied to regular terminals.

With 20 agent panels open — a common scenario in Canopy — scrollback buffers alone consume ~75MB. At the maximum 10,000-line agent cap, that rises to ~300MB. VS Code defaults to 1000 lines; Canopy's 2500-line default is 2.5× more aggressive.

The default was already reduced from 5000 to 2500 at some point, but even 2500 is high for a product whose primary use case involves many simultaneous terminals rather than a single deep session.

Current Configuration

• Default: SCROLLBACK_DEFAULT = 2500 in shared/config/scrollback.ts
• Agent policy: max 10,000 lines, multiplier 1.0 — AGENT_SCROLLBACK_POLICY in src/utils/scrollbackConfig.ts
• Main-process default: scrollbackLines: 2500 in electron/store.ts
• Regular terminal policy: multiplier 0.2, max 2000 — already much lower than agents

The SCROLLBACK_MAX = 10000 cap and the performance-mode override (PERFORMANCE_MODE_SCROLLBACK = 100) show the infrastructure for multiple tiers already exists; the base default just needs adjusting.

Desired Behavior

The default scrollback should be reduced to a value that is reasonable for interactive use while meaningfully cutting memory pressure when many agent panels are open. The full configurable range (100–10,000) should remain available for users who want more. Agent terminals should have a lower maximum cap than the current 10,000.

The memory estimate display in the scrollback settings UI should remain accurate after any changes to defaults or policies.

Acceptance Criteria

• The default scrollback setting produces meaningfully lower memory usage when 10+ agent panels are open simultaneously
• The user-visible settings range (minimum/maximum/default) is internally consistent — the UI memory estimate reflects the actual behavior
• Users who have not explicitly changed the scrollback setting are migrated to the new default on next launch (or the existing migration path handles this)
• Existing behavior for users who manually set scrollback above the new default is preserved
• The estimateMemoryUsage helper and scrollback summary UI in settings remain accurate

Edge Cases & Risks

• Users relying on deep scrollback for reviewing long agent output may notice history truncation on the next session (a migration notice or settings callout would help)
• The agent maximum cap change should not break agent state detection, which reads the last ~50 lines of output for heuristics