MAINT Split MessageList view models from rendering

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

frontend/src/components/Chat/MessageList.tsx combines several distinct responsibilities: mapping backend messages into render pieces, JSON formatting, Markdown/plain-text presentation, image/audio/video fallback behavior, attachment downloads, score selection and overflow measurement, action-policy decisions, scrolling, and the full message-row layout.

The concern is responsibility concentration rather than file size alone. Pure data-shaping rules and DOM measurement are interleaved with Fluent UI rendering, which makes score, media, and action behavior harder to test independently and increases the chance that a visual refactor changes message semantics.

Describe the solution you'd like

Separate the pure message view model from focused presentation components. A reasonable boundary could include:

• a pure typed mapper that produces renderable message pieces and presentation metadata;
• a message row/piece renderer;
• attachment and media renderers with loading/error fallback;
• a score component responsible for score ordering, selection, overflow, and details;
• an action component responsible for copy and branch availability;
• MessageList retaining list iteration, loading/empty states, and scroll-to-end behavior.

Reuse existing shared frontend types and keep component-local types local. Avoid a generic renderer abstraction that hides the supported message-piece variants. The mapping layer should make those variants explicit and exhaustive.

Preserve message ordering, Markdown behavior, JSON formatting, score precedence and labels, media fallback, downloads, action availability, tooltips, keyboard behavior, accessibility names, and test IDs.

Describe alternatives you've considered, if relevant

Moving helper functions into a utility file without defining an explicit view-model boundary would reduce line count but not clarify ownership. Splitting every small Fluent UI fragment into a component would add indirection without reducing the coupled score/media/action logic.

Additional context

This was identified during the September 14, 2026 maintainability audit. A repository issue search found no exact existing tracker.

Suggested regression coverage:

• backend messages mapped with real typed message/piece instances;
• text, JSON, Markdown, image, audio, video, and generic-file pieces;
• media loading and error fallbacks;
• objective-score precedence and multiple-score overflow selection;
• resize-driven score-tab overflow;
• attachment download success/failure;
• single-turn, operator-locked, cross-target, and no-target action policies;
• accessible labels and keyboard interaction for menus, tabs, and actions.

Definition of done:

• pure message shaping can be tested without rendering Fluent UI;
• media, score, and action presentation have focused component tests;
• MessageList is the list-level composition boundary rather than the owner of every piece behavior;
• no public props, accessibility, or user-visible output changes;
• frontend unit tests, type-check, lint, and formatting pass.