Add per-user custom color themes across the v2 UI

[Bionic711]

Summary

Add per-user custom color themes to the v2 UI so users can personalize most application-owned UI elements, rather than being limited to the default light/dark palettes or conversation-message colors alone.

User Value

Users have different visual preferences and readability needs. App-wide color customization would improve comfort during long sessions, distinguish important UI elements, and provide a consistent personal appearance without changing other users' experience or deployment-wide branding.

Proposed Behavior

• Add a Custom theme editor within the v2 user's appearance settings, with a color picker and validated hex-color input for supported color roles.
• Start from the current light or dark theme and let users override individual colors; unspecified values continue to inherit the base theme.
• Organize controls by UI area, with a live preview containing navigation, conversation messages, form controls, a table, code, and feedback examples.
• Provide Save, Cancel, reset for an individual color, and Reset to default actions. Preview changes must not overwrite saved preferences until the user saves.
• Save preferences to the user's profile so they persist across sessions and devices. Theme changes affect only that user.
• Define predictable light/dark behavior, preferably storing overrides separately for each base mode to avoid carrying unsuitable colors into the other mode.

Proposed Customizable UI Colors

Use shared semantic color roles where appropriate so users do not need to configure every instance of a component.

UI area	Suggested configurable colors
Application canvas	Page background, main content background, chat canvas background
Cards and overlay surfaces	Card/panel backgrounds, modal/drawer backgrounds, header surfaces, borders
Sidebar and top navigation	Background, labels, icons, hover background, active item background and foreground
General text	Primary text, secondary/muted text, headings, help text
Accents and links	Primary accent, link text, link hover, selected-text and search-result highlights
Buttons	Primary, secondary, and destructive button backgrounds, labels, and borders
Form fields	Input/select/textarea backgrounds, entered text, placeholder text, borders
Selection controls	Checkbox/radio selected fill, check marks, toggle track and thumb colors
Conversation list	Item background, active/hover selection, title/metadata text, unread indicators
Conversation messages	Independent user-message and assistant-message backgrounds and text colors; coordinate with #1037
Message composer	Composer background and border, text and placeholder, attachment/tool icons, send-button colors
Tables and lists	Header background/text, row and alternating-row backgrounds, selection/hover, grid borders
Markdown and code	Inline-code background/text, fenced-code background and syntax palette, blockquote background/accent
Badges, tags, and citations	Chip background/text/border, document and workspace tags, citation markers
Alerts and notifications	Success, warning, error, and informational foreground/background/border colors for banners and toasts
Supporting UI and interaction states	Dividers, generic icons, tooltip/menu surfaces, keyboard-focus outline, progress bars and loading indicators

Derive hover, active, focused, selected, and disabled states consistently from the palette by default. Keep foreground/background pairs understandable in the editor and avoid requiring users to maintain many unrelated color values.

Accessibility and Safety

• Provide contrast feedback and actionable warnings for configured foreground/background pairs, using WCAG AA targets: 4.5:1 for normal text, 3:1 for large text, and 3:1 where applicable to meaningful non-text UI boundaries and indicators.
• Keep accessible built-in defaults, clearly visible keyboard focus, and labels/icons that communicate status without relying on color alone.
• Preserve operating-system forced-colors/high-contrast behavior.
• Accept only validated color values and supported theme keys; do not accept arbitrary CSS, HTML, scripts, or external asset URLs.

Acceptance Criteria

• A signed-in user can create and edit a personal v2 theme using the proposed UI color groups, with any unsupported groups explicitly documented.
• Changes appear in a representative live preview before saving; Cancel restores the previously saved appearance.
• Saved themes persist across sessions and devices and do not affect another user's preferences or administrator branding settings.
• Unset colors inherit the selected base theme; users without custom preferences retain the current appearance unchanged.
• Switching between light/dark modes preserves the appropriate overrides without producing unintended foreground/background combinations.
• Individual-color reset and full reset restore the expected defaults.
• Shared components use the selected colors consistently across v2 pages, including content added dynamically while chatting or navigating.
• Markdown, code, tables, citations, streaming responses, mobile layouts, and keyboard interaction remain usable.
• The editor provides contrast feedback, rejects invalid values/unsupported keys, and keeps accessible default palettes available.
• Focused tests cover validation, per-user persistence/isolation, preview/save/cancel/reset, mode switching, and representative component rendering; user documentation explains customization and limitations.

Scope and Related Work

• Related: Add per-user conversation appearance controls #1037, Add per-user conversation appearance controls. That issue focuses on message colors and font sizes; this issue extends color customization across the v2 application. Reuse or align its preference storage and message-color controls rather than creating competing settings.
• This issue covers UI colors, not font/layout customization, a theme marketplace, arbitrary stylesheet uploads, or changes to administrator-controlled logos and branding.
• Generated chart/diagram data-series palettes and colors inside uploaded documents or images are separate from application chrome and are not automatically recolored by this feature.
• Prefer shared semantic design tokens/CSS custom properties, or the equivalent existing v2 theming mechanism, over per-component hard-coded overrides.
• Priority: P2.
• Estimated size: M (theme editor, user-preference persistence, component color-role integration, and validation).