MAINT Decompose ChatWindow conversation workflows #2652

Is your feature request related to a problem? Please describe.

frontend/src/components/Chat/ChatWindow.tsx still owns the send/recovery and copy/branch orchestration, including per-conversation locks, optimistic messages, attachment/conversion state, and navigation during those operations.

Loading and stale-fetch protection are already extracted into useConversationMessages by merged #3310. Human-score/objective mutations and export are already extracted into useAttackMutations and useConversationExport by merged #3369. Those are completed steps of this issue, not workflows to extract again.

The concern is not line count by itself. Race-sensitive state is spread across React state, multiple refs, effects, and callbacks, so changing one workflow requires understanding unrelated behavior. The associated tests also have to render a large surface to verify small state transitions.

Describe the solution you'd like

Decompose the stateful workflows behind focused hooks or reducers while keeping ChatWindow as the composition and presentation boundary. Candidate boundaries include:

• message sending, optimistic state, per-conversation locking, attachments, and conversions;
• copy/new-conversation/branch-conversation/branch-attack operations;
• the remaining coordination between those operations and the already-extracted loading, mutation, export, conversation-draft/save, and converter hooks.

Reuse useConversationMessages, useAttackMutations, useConversationExport, useConversationDraft, useConversationSave, and useChatConverters. Extract the remaining orchestration, not another persistence service, converter implementation, or conversation loader.

Keep state together when it participates in the same transition. Prefer an explicit reducer for multi-step conversation mutation state over moving individual useState calls into pass-through hooks. The extracted APIs should return typed state and commands with clear ownership.

Preserve the existing ChatWindow props, rendered UX, accessibility, request payloads, optimistic-message behavior, navigation behavior, and error handling. In particular, retain the current protections against stale conversation loads, duplicate sends/exports, navigation during an in-flight send, and mutation while an operation is locked.

Describe alternatives you've considered, if relevant

Extracting only JSX sections into presentational components would shorten the file but leave the hard part, asynchronous state ownership, unchanged. Creating one large useChatWindow hook would move rather than reduce the complexity. The goal is a few cohesive workflow boundaries, not maximal file splitting.

Additional context

This was identified during the September 14, 2026 maintainability audit. Scope refreshed against main 791e12c6e5e4302e7c1211af6af8973aa6fe1f37 on October 31, 2026. #3310 and #3369 are merged partial delivery; continue this existing tracker rather than start the original decomposition again.

Coordinate remaining ChatWindow edits with dataset import #2751/#3670 and the active Chat/UI stack. Saved Scenario evidence paging is a different consumer of the existing loader and renderer, not permission to rewrite manual Chat here.

Suggested regression coverage:

• switching conversations while a fetch is in flight;
• sending independently in two conversations;
• preserving optimistic messages when the active conversation changes during send;
• duplicate-send and duplicate-export prevention;
• copy to current/new conversation and both branch paths;
• mutation locking during score, objective, and conversation updates;
• attachment and converted-piece handling;
• narrow-screen panel behavior.

Definition of done:

• each extracted hook/reducer owns one cohesive workflow and has focused tests;
• ChatWindow primarily composes workflow state and renders children;
• no public API, backend contract, accessibility, or user-visible behavior changes;
• frontend unit tests, type-check, lint, and formatting pass.