Add per-user custom color themes across the v2 UI

@paullizer is already working on this.

Since Sep 8, 2026.

## 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: #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).