fix(chat): space a run of tool rows as one block, prose as a new thought

[ElbertePlinio]

What was left of #367

PR #366 landed two thirds of it: the dead 48px measured-row floor, and the compact estimates that were 2–3× their real heights. It also took --pf-chat-virtual-gap from 12px to 4px globally.

That fixed the run but left prose just as tight. Every pair in the timeline was spaced identically, so nothing in the layout distinguished a burst of work from a change of subject — #367's own acceptance criterion ("consecutive CMD/TOOL/MCP rows sit visibly closer than a row adjacent to prose") was still false, now from the other direction.

The decision

Two tiers, spacing only:

Pair	Token	Value
compact ↔ compact	--pf-chat-virtual-run-gap	--pf-space-xs (4px)
any pair with a prose/card side	--pf-chat-virtual-gap	--pf-space-md (12px)

3:1 was chosen from rendered comparison, not picked. At 8/4 the boundary was only barely distinguishable from the run at a glance; at 12/4 the burst reads unmistakably as one block and prose visibly opens a new thought.

Note this partially re-widens what #366 tightened — prose returns to exactly its pre-#366 gap. Calling that out rather than burying it: #366's real win was the floor and the estimates, which is why rows stay tight regardless; the global gap reduction was collateral, and it made prose pay for a problem that belonged to tool runs.

Compact = command, toolUse, mcpToolCall, webSearch, collapsed thinking, and the transient working row. Classification is kind-based on purpose: a row the reader expanded is still part of its burst, and keeping it kind-based keeps buildTimelineLayout pure.

No grouping chrome. The issue floated a shared left edge. The .pf-chat-line rows already carry one, and at a 4px pitch those existing edges do the grouping — a run-spanning rail would be new chrome for nothing, against the standing rule to reuse an edge that already exists.

Scroll safety

applyRowHeights is untouched — it carries the standing TODO(#263) complexity exemption and #366 just did delicate work there for #352. The gap choice lives entirely in the pure layout function, and the anchor path still compares the same starts before and after, so a row shrinking above the viewport compensates exactly as before.

Coverage this adds

tauriMock emitted no toolUse / mcpToolCall / webSearch items at all, so those rows had zero VRT coverage. Adds a gated agentChatToolRun fixture — prose → thinking → six consecutive commands → tool/mcp/web → prose → usage — and a VRT assertion that compares gaps by bounding box, so it pins the density independently of any baseline.

Validation

• bun run test:unit — 115 files, 1570 passed
• bunx tsc --noEmit clean, bun run lint clean (incl. check-design-tokens)
• Rendered before/after on an isolated port at 12/4 and 8/4 before locking the ratio
• Load-bearing verified independently: reverting buildTimelineLayout to the uniform gap fails the three new layout tests; removing thinking from the compact set fails the classification test

VRT baselines will legitimately change and need the update-vrt-baselines workflow; the new agent-chat-tool-run baseline comes from there too.

Open decisions carried forward

• usage treated as not compact, so a turn's token/cost receipt takes the wider distance after the last row. Low-confidence taste call; hugging the turn at 4px is defensible.
• Run tightness does not loosen when a row is expanded — deliberate, but it is a simplification worth stating rather than discovering.

Closes #367