tooling: in-app memory snapshot command to attribute RAM growth

[Axelj00]

Problem

Users report ClawTerm "eating insane amounts of RAM" and we have no way to confirm where it's going without asking them to attach a Chrome devtools heap snapshot. That's a tall order — the user has to know about `tauri::WindowExt`, open devtools in a webview that doesn't expose it by default, take the snapshot, and ship a multi-MB file.

Meanwhile our internal mental model of "where the RAM goes" is fragmented across:

• xterm.js scrollback (5000 lines × N panes, compacted to 1000 when hidden via No memory limit on xterm.js scrollback — each pane can consume unbounded memory #305)
• xterm.js ImageAddon storage (128 MB default — see perf: ImageAddon defaults to 128 MB storage per pane — multi-pane sessions can hit GBs #565)
• WebGL contexts (pooled to 6, WebGL context create/destroy on every tab switch — expensive GPU round-trips #290)
• output-analyzer eventHistory (RingBuffer × 200)
• Notification tray (50 records)
• Closed-tab undo stack (10 entries)
• PTY pending-write buffer (128 KB cap per hidden pane)
• Tauri webview Chromium baseline (opaque)
• Rust process RSS (opaque)

A user reporting "ClawTerm is using 3 GB" gives us no idea which of the above is the culprit. We're flying blind.

Proposal

Add a `Memory Diagnostics` command in the palette that produces a structured report:

```
ClawTerm Memory Snapshot — 2026-05-23 22:00:00

Tabs: 4 Panes: 8 WebGL contexts: 6/6

Per-pane (8 panes):
pane-1 scrollback=5000 image=42MB pending=0KB
pane-2 scrollback=5000 image=128MB pending=0KB ← image cap hit
pane-3 scrollback=1000 image=8MB pending=0KB (hidden, compacted)
...

Aggregated:
Scrollback total ~35 MB (estimated, 480 B/line × cols)
Image storage total ~340 MB ← largest contributor
Event history total ~1 MB
Tray records 50 entries (~25 KB)
Closed-tab stack 10 entries (~5 KB)

JS heap (performance.measureUserAgentSpecificMemory):
Total: 480 MB (Web platform measurement, Chromium only)

Process RSS (from get_self_rss IPC):
680 MB ← what Activity Monitor shows
```

Easy to copy-paste into a bug report. Easy for us to read and immediately know "image storage is 340 MB → check #565 / lower the cap."

Implementation sketch

1. `ImageAddon.storageUsage` (MB) is already exposed by the addon — call per-pane.
2. `Terminal.buffer.active.length` for scrollback line count.
3. `pendingBytes` is already tracked per pane.
4. `performance.measureUserAgentSpecificMemory()` for JS heap — requires the page to be cross-origin-isolated; verify Tauri webview qualifies.
5. New Rust command `get_self_rss` calling `proc_pidinfo(getpid(), PROC_PIDTASKINFO)` — we already have the syscall wrapper from Show per-pane memory usage (RSS) in the footer #560.
6. Command palette: "Memory Diagnostics" → modal showing the report + a "Copy to Clipboard" button.

Why this is worth building

Two reasons:

1. Self-diagnosis. The user can answer "is it the images or the scrollback?" themselves without filing an issue.
2. Triage. When users do file RAM complaints, we can ask them to run this command and paste the output. Better than a flame-graph upload.

Reuses the modal pattern from #553 / #554 — small surface, large clarity gain.

Out of scope

• Continuous monitoring / leak detection. One-shot snapshot is enough.
• GC-trigger button — Chromium will GC under pressure; we don't need a button.
• Per-pane breakdown of WebGL GPU memory — not exposed by the WebGL spec.

References

• ImageAddon storage usage API: `node_modules/@xterm/addon-image/typings/addon-image.d.ts:103` (`readonly storageUsage: number`)
• Existing proc_pidinfo wrapper: `src-tauri/src/process_info.rs::platform::proc_resident_size` (Show per-pane memory usage (RSS) in the footer #560)
• Existing modal pattern: `src/notification-tray.ts` (notifications: in-app 'missed events' tray — what did I miss while away #554)

[Axelj00]

Adding long-session-specific scope based on the use case of weeks-long ClawTerm runs:

Additional metrics to include in the snapshot:

• Uptime (process start time → now). Date.now() - performance.timeOrigin for the renderer; the new get_self_rss IPC could also report the Rust process start time.
• /tmp/clawterm-status/ file count (related to perf: claude_status stale-file sweep only runs at startup — accumulates over weeks-long sessions #567). A growing count points at the statusline sweep gap.
• logger ring buffer fullness (logger.getBufferSize() already exposed). At LOG_BUFFER_MAX=2000, if it's full the user has been running long enough that the oldest log lines have rotated out — useful context for triage.
• xterm.js scrollback line counts per pane. Confirms whether scrollback is at the 5000 cap (config) or compacted to 1000 (hidden). The user comparing these to their config tells us if the compaction is working.
• branchColorCache size (capped at 256 in tab-state.ts:371) — useful as a proxy for 'how many unique branches has this session seen' which correlates with worktree-heavy workflows.
• WebGL pool occupancy (pool.lru.length / maxContexts).

Why long-session-specific: a 5-minute session and a 3-week session have completely different memory-shape expectations. Without uptime + ring-buffer-fullness + scrollback-line-count signals in the report, we can't tell whether 'this user has been running for hours' or 'this user has been running for weeks.' Same RSS number tells very different stories at each scale.

Suggested format addition — header line right after the title:

ClawTerm Memory Snapshot — 2026-05-23 22:00:00
Uptime: 12d 4h 30m   Log buffer: 2000/2000 (saturated)   Statusline files: 47

That single header tells us "this is a multi-week session, the log buffer has rotated, and stale statusline files have accumulated" — enough context to know which other numbers are interesting before scrolling.