perf(desktop): bound tool-result rendering so big /learn runs don't freeze

[OutThisLife]

Problem

/learn over a large file/directory makes the desktop app hang/throttle forever or crash outright — the agent's gathering loop never visibly completes. (Reported: "On large files/directories, the desktop app either crashes completely or just hangs/throttles forever without actually executing the learning process.")

It is not a /learn bug — build_learn_prompt() is fixed-size and never embeds file contents. The fault is in the desktop tool renderer.

Root cause

ToolFallback constructs a fresh part object on every render:

const part: ToolPart = { args, isError, result, toolCallId, toolName, type: 'tool-call' }

That fresh reference defeats the useMemo around buildToolView, which unconditionally JSON.stringifys the entire result (rawResult) and extracts the full detail. During a /learn run over a big directory — many ~100KB tool results — every ~33ms stream flush re-renders the thread and re-serializes every row: the main thread saturates (hang/throttle) and accumulated strings spike renderer memory (crash). Small dirs never trip it because results are few and tiny.

Fix

• Stabilize the memos. Re-derive a stablePart from the referentially-stable args/result/… and key buildToolView + toolCopyPayload on it, so they recompute only when this tool's data changes — not on every unrelated stream delta.
• Bound what's painted. New clampForDisplay (MAX_TOOL_RENDER_CHARS = 20_000) applied to prettyJson (rawArgs/rawResult), rawTechnicalTrace, and the rendered detail/stdout/stderr blocks, with a "… N more characters truncated — use Copy" notice. The row's Copy button still reads the uncapped view.detail, so the full output is one click away.

No new core surface, no schema change — purely desktop renderer.

Test plan

• vitest run apps/desktop/src/components/assistant-ui/tool-fallback-model.test.ts — 14 passed (3 new: clamp pass-through, truncation + omitted-count, buildToolView rawResult cap)
• tsc -p apps/desktop --noEmit — clean
• eslint on changed files — clean (pre-existing model-file lints left untouched)
• The 7 failing assistant-ui tests (block-direction/streaming/user-message-edit) are pre-existing jsdom-layout failures — confirmed identical with these changes stashed