[ENHANCEMENT] Extract ChatView message-derivation pipeline

[WebMad]

Problem (one or two sentences)

The message preparation logic in webview-ui/src/components/chat/ChatView.tsx mixes filtering, batching, grouping, metrics, todos, and checkpoint derivation into an already large UI component. This makes chat rendering behavior difficult to review and increases the risk of regressions when changing message visibility or presentation.

Context (who is affected and when)

This primarily affects contributors working on the chat UI, but users are affected when changes in this area cause duplicated or missing rows, incorrect tool batching, unstable long-chat rendering, or checkpoint actions attaching to the wrong message. The risk is highest during streaming, task rehydration, and long conversations where the complete message pipeline is recomputed frequently.

Desired behavior (conceptual, not technical)

Chat message preparation should live in a small, focused, independently tested unit. ChatView should consume a stable message view model and remain responsible for orchestration and layout rather than implementing the full message-transformation pipeline.

Constraints / preferences (optional)

• Preserve current rendering and interaction behavior; this is a behavior-neutral extraction.
• Keep pure message transformations separate from effects and user actions.
• Do not change approval state, send/queue behavior, or scroll lifecycle in this work.
• Prefer focused pure selectors and/or a narrow hook over introducing a broad new state-management abstraction.
• Keep the change reviewable as an independent refactoring slice.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

N/A

Acceptance criteria (optional)

• The message-derivation pipeline is extracted from ChatView.tsx into a focused module or hook.
• The extracted unit covers combined API requests and command sequences, visible-message filtering, tool-request batching, grouped messages, completion checkpoint metadata, checkpoint indices, API metrics, and latest todos.
• Inputs are limited to the source message data and the small amount of task/UI state required for derivation, such as current task todos and condensation state.
• ChatView consumes a stable derived view model rather than implementing these transformations inline.
• Focused tests characterize filtering, batching, grouping, and derived metadata behavior.
• Existing chat rendering and interaction tests continue to pass without intended behavior changes.
• Approval handling, input/send/queue behavior, and useScrollLifecycle remain out of scope.

Proposed approach (optional)

Introduce a focused message-derivation layer, for example useChatMessages backed by pure selectors. Move the existing transformation pipeline into that layer in small steps, add characterization tests for current behavior, and update ChatView to consume the returned view model.

Related issues:

• [ENHANCEMENT] Extract ChatView ask/footer state for approval-flow work #103 covers the separate extraction of ask/footer state.
• UI tool ask batching fails when models insert API rows between tool calls #1004 addressed one batching defect and demonstrates why batching behavior needs focused tests.
• [BUG] Chat window state duplicated (messages/blocks render twice), not limited to one mode #325 tracks duplicated chat rows after state updates or rehydration.
• fix(webview): throttle state pushes to prevent gray screen OOM at high message counts #629 documented long-chat webview memory pressure.

Trade-offs / risks (optional)

The main risk is accidentally changing message ordering, visibility, grouping, or identity during a nominally behavior-neutral refactor. Characterization tests should be added before or alongside each moved transformation. The extraction should avoid becoming a single oversized hook that merely relocates the existing complexity.

[WebMad]

CHAT_VIEW_DECOMPOSITION_PLAN.md