WIP: feat(tui): TUI theme presets (Dune and Neon)

[euxaristia]

Summary

Adds two TUI color themes, Dune (light, warm sand/amber) and Neon (dark, black/green/cyan), as entries in the existing palette-registry system. Addresses the proposal in #633.

Changes

• Added dunePalette and neonPalette as palette entries in internal/tui/theme_palettes.go, registered in themeRegistry alongside the existing themes.
• Both resolve through the existing --theme, ZERO_THEME, /theme, and picker paths. No new theming architecture was introduced.
• Documented the two themes and the palette-registry extension pattern in docs/THEMES.md.
• Added dune and neon to the ZERO_THEME/--theme tables in README.md and README_ZH.md.
• Added tests in theme_select_test.go covering registry wiring, CLI/env resolution (resolveThemeMode, applyTheme), and WCAG AA contrast for both palettes across permission surfaces, selected-row text, and diff gutters.

Notes

An earlier version of this PR introduced a standalone Theme interface with its own layout, margin, and border model. That replaced the tuiTheme/buildTheme/palette architecture every renderer depends on, used the wrong lipgloss import, and broke the build. It was reverted; the current implementation only adds palette entries following the file's existing extension pattern, not new layout infrastructure.

[jatmn]

I found an issue that needs to be addressed before this is ready.

Findings

• [P0] Restore a buildable theme runtime before replacing the existing palette
  internal/tui/theme.go:4
  This imports github.com/charmbracelet/lipgloss, which is not a module dependency (the project uses charm.land/lipgloss/v2). More importantly, this replacement removes palette, tuiTheme, buildTheme, and zeroTheme, which theme_palettes.go, theme_select.go, and the rest of the TUI still compile against. Consequently every PR-owned CI job is failing: the release/smoke build stops at this import and the security check then reports the missing palette symbols. Please preserve or port the current palette runtime and migrate all consumers before adding the new interface, then update the PR with passing CI evidence.

• [P1] Connect the new presets to the theme selection and rendering paths
  internal/tui/theme.go:27
ClaudeTheme and CodexTheme are only declared here. They are absent from themeRegistry, which is the sole source for --theme, ZERO_THEME, persisted preferences, /theme, and the picker, so both names are rejected or omitted today; no renderer consumes any of the new interface methods either. Please wire the presets through the registry/selection and rendering paths (with coverage), or keep this as documentation until the implementation can be added in a complete change.

[jatmn]

Thanks for the update. I rechecked the changed paths and found several issues that still need to be addressed.

Findings

• [P2] Make the Claude permission and semantic text meet AA
  internal/tui/theme_palettes.go:448
  The new Claude palette renders the permission-card heading as amber on permBg at 3.13:1 and the PERMISSION badge as onAccent on amber at 3.85:1. Its green success text and amber warning/mode text are also only 4.16:1 and 3.43:1 against the panel. These are normal text on safety/status surfaces, but the registry test passes because it checks only neutral/accent tokens against the panel and onAccent against accent, not the actual pairings built in buildTheme. Please choose compliant tokens and extend the registry invariant to cover every foreground/background pair the renderers actually use, including limited-terminal conversion.

• [P2] Keep selected-row metadata readable in both presets
  internal/tui/theme_palettes.go:359
internal/tui/theme_palettes.go:459
  Selected picker and manager rows render descriptions with faint and right-side metadata with faintest on selBg. Codex's faintest/selBg ratio is 3.38:1, while Claude's faint and faintest pairings are 3.65:1 and 3.58:1. As a result, filtering or moving through theme/model/provider lists makes the secondary text sub-AA even though TestSelectedRowBandIsVisibleAndReadable passes because it checks only ink on selBg. Please adjust the selected surfaces/tokens and cover the actual secondary-text pairings.

• [P2] Fix diff-gutter contrast in both new palettes
  internal/tui/theme_palettes.go:354
internal/tui/theme_palettes.go:454
  Diff line numbers use faintest on addBg/delBg, and signs use green/red on those bands. Codex's added-line number is only 4.01:1; Claude's added/deleted numbers are 4.48:1 and 4.22:1, and its added sign is 4.05:1. These are the exact styles emitted by addLineNum, delLineNum, addSign, and delSign, but the current tests cover body/word-span ink rather than gutter text. Please correct both palettes and add invariants for the gutter pairings (including ANSI-256 downsampling, where more of them fall below AA).

• [P2] Complete the earlier wiring request with load-bearing coverage
  internal/tui/theme_palettes.go:493
internal/tui/theme_palettes.go:496
  The previous review asked for the presets to be wired through selection “with coverage,” but no test independently requires either new registry entry. Removing both codex and claude entries through a read-only Go overlay still leaves the focused theme suite and the full internal/tui package green. Please complete that review request with explicit tests that require both names to resolve, validate through the CLI/env path, appear in the correct picker group, and apply their intended palette.

• [P2] Align the PR contract with the palette-only implementation
  docs/THEMES.md:12
docs/THEMES.md:17
  The PR title/body and linked #633 describe Claude's centered/card/sidebar layout and Codex's split-screen/dense/status layout, and the body still claims a Theme interface was added in theme.go via local file:/// links. The current implementation has only Palette/IsDark; no layout composition path branches on either preset, so selecting them changes colors but not density, spacing, cards, sidebar behavior, or status layout. Please either implement the promised arrangements or retitle and rewrite the PR/body/docs as a color-palette addition, remove the density/layout claims, and add the UI screenshots/verification required by CONTRIBUTING.md.

• [P2] Preserve the repository's neutral runtime branding decision
  internal/tui/theme_palettes.go:493
internal/tui/theme_palettes.go:496
  Merged PR #307 deliberately scrubbed named other-agent/CLI references from TUI code and replaced them with neutral language, retaining names only for real integrations or explicit competitor positioning. These picker-visible Claude and Codex imitation presets reintroduce the exact runtime branding that decision removed, and linked issue #633 contains no maintainer note reversing it. Please use neutral Zero-owned theme names (and neutral comments/docs), or obtain an explicit maintainer decision that supersedes #307 before exposing these names in the runtime catalog.

[euxaristia]

Addressed the review. theme.go's replacement had thrown away the tuiTheme/buildTheme/palette system every renderer depends on and used the wrong lipgloss import, which broke the build. Restored that architecture and added the two new presets (now named dune and neon, renamed from claude/codex per the branding concern raised) as real palette entries following the file's existing extension pattern, wired into --theme, ZERO_THEME, /theme, and the picker through the existing registry. Fixed the additional AA contrast failures in the permission surfaces, selected-row text, and diff gutters, and added tests requiring both names to resolve through the CLI/env path and appear in the correct picker group, not just non-regression. Rewrote THEMES.md and the PR body to describe the actual palette-only implementation instead of the interface and layout claims that were never built.

[jatmn]

I found issues that need to be addressed before this is ready.

Findings

• [P2] Restore AA contrast for Dune selected-row affordances
  internal/tui/theme_palettes.go:459
  The selected-row renderers put the caret (accent) and local-model dot (blue) on selBg via onSel (for example, internal/tui/view.go:771-780). In Dune those pairs are only 4.00:1 (#8f5215 on #e0cf98) and 3.61:1 (#3d6a9e on #e0cf98), so the active selection and local status become sub-AA. The added invariant covers only faint and faintest on that background, so it does not catch either rendered pairing. Adjust the palette and test the actual selected-row foregrounds.

• [P2] Keep Dune's deleted-diff sign readable after ANSI-256 downsampling
  internal/tui/theme_palettes.go:449
delSign renders red on delBg. Although the true-colour pair passes, standard xterm-256 conversion maps it to #875f5f on #ffd7d7, about 4.16:1, below AA. This is the limited-colour path the palette contract says must remain readable, but the new test only measures raw hex values. Choose a pair that survives the conversion and add coverage for the ANSI-256 rendering path.

• [P2] Align the PR contract with the palette-only implementation
  PR title and description
  The current title/body still say this adds Claude/Codex layouts and a dynamic Theme interface, while the head adds only the neutral Dune/Neon palette registry entries; docs/THEMES.md:21-26 explicitly describes that palette-only design. This leaves the previously requested contract correction incomplete and causes reviewers to evaluate a feature the PR does not implement. Update the GitHub title and description to describe the actual Dune/Neon palette addition, or implement the advertised layout work.

• [P3] Document the command that actually lists theme state
  docs/THEMES.md:3
  The new documentation says bare /theme shows the active theme and names, but command dispatch opens the live-preview picker for that form; only /theme list calls the state/list output (internal/tui/theme_select.go:118-124,162-182). Document /theme as opening the picker and /theme list as the read-only state/list command.

• [P3] Update the primary theme inventories for the new presets
  internal/tui/theme_palettes.go:493
neon and dune are accepted by --theme and ZERO_THEME, but the enumerated valid-name tables in README.md:325-326 and README_ZH.md:255-256 still omit both names while saying the CLI accepts the same list. Add the two presets to those user-facing inventories (or stop presenting the list as exhaustive).

[euxaristia]

Pushed 74f570a for jatmn's third round:

• Raised Dune's accent (#8f5215 -> #7c4712) and blue (#3d6a9e -> #2f5680) so the selected-row caret and local-model dot clear AA contrast against selBg (were 4.00:1 and 3.61:1, now 4.90:1 each).
• Raised Dune's red (#963328 -> #872d24) so it clears AA both in true-color and after ANSI-256 downsampling against delBg (the true-color value already passed at 5.70:1, but its 256-downsampled pair was only 4.35:1).
• Rewrote the contradictory docs/THEMES.md paragraph: bare /theme opens the live-preview picker, /theme list prints the registered names.
• Added dune and neon to the ZERO_THEME/--theme tables in README.md and README_ZH.md.

Also retitled/re-bodied the PR itself: it was still titled "WIP: TUI Theme Presets (Claude and Codex)" and described ClaudeTheme/CodexTheme in the body, but the actual presets are named Dune and Neon per the #307 naming decision.

Contrast values were checked against this repo's own WCAG math plus the actual xterm 256-color downsampler used at render time, not eyeballed; all of TestExtendedThemeContrastInvariants, TestAllThemesContrastAndHierarchy, TestSelectedRowBandIsVisibleAndReadable, TestDiffWordSpanContrast, and TestLightPaletteContrastAndHierarchy pass.

[jatmn]

I found issues that need to be addressed before this is ready.

Findings

• [P1] Make the new Dune contrast test pass
  internal/tui/theme_palettes.go:446-459
TestExtendedThemeContrastInvariants directly checks faintest on selBg and delBg, but the introduced values are only 3.72:1 (#655648 on #e0cf98) and 4.28:1 (#655648 on #f5dbd5). Consequently the test added in this PR reports both failures when the TUI test package is run, despite the claimed AA coverage. Adjust the palette (and recheck every asserted pairing) so the test suite can actually pass.

• [P2] Preserve Dune's selected-row affordances in ANSI-256 terminals
  internal/tui/theme_palettes.go:447-459
  Selected picker rows render accent and local-model blue on selBg through onSel (internal/tui/view.go:768-783). The true-colour pairs are already below AA (about 4.07:1 and 4.04:1); after xterm-256 conversion the accent pair is lower still (#875f00 on #d7d787, about 3.81:1). The added tests only inspect raw hex tokens, so they cannot protect the documented limited-colour rendering path. Choose tokens that remain compliant after conversion and test the rendered ANSI-256 pairs.

• [P2] Keep Neon diff bands distinguishable after ANSI-256 downsampling
  internal/tui/theme_palettes.go:354-357
  On a 256-colour terminal, both base backgrounds (addBg and delBg) quantize to the same gray, and both word-span backgrounds quantize to the same gray. Added and deleted rows therefore lose their intended background distinction, and highlighted changed spans no longer identify which kind of diff they belong to. The existing invariants measure only true-colour contrast/separation; use ANSI-256-safe green/red bands and cover that profile in the regression test.

• [P3] Add the new theme guide to the documentation index
  docs/THEMES.md:1
  This new user guide is not linked from the canonical Documentation section in README.md (or its Chinese counterpart), and no other repository file links to it. Users can discover the two names from the environment-variable table but cannot discover the picker behavior or extension guidance. Add it to the maintained documentation indexes.

• [P3] Update the Unreleased theme inventory
  CHANGELOG.md:134-137
  The Unreleased changelog still promises exactly ten color themes and enumerates the old set, while this change registers Dune and Neon as the eleventh and twelfth. Release-note consumers will receive an inaccurate feature list; update the count and inventory alongside the README tables.

[euxaristia]

Pushed cdf8149 for the latest round.

On the first finding: TestExtendedThemeContrastInvariants passes at the previous head 74f570a. The quoted ratios (3.72:1 for faintest on selBg, and 4.07/4.04 for accent and blue) match the palette before 74f570a, which raised accent to #7c4712 and blue to #2f5680; after that push faintest on #e0cf98 computes to 4.55:1 and faintest on #f5dbd5 to 5.36:1 by the WCAG formula, and the suite is green. So I treated that finding as already addressed and focused on the ANSI-256 findings, which were still real.

• Dune: #7c4712 quantized to #875f00, which is only 3.81:1 on quantized selBg. The accent is now #724028: 5.46:1 on selBg and 7.03:1 on panel in truecolor, and its xterm-256 quantization (#444444) clears AA at 6.47:1. Blue already survived quantization at 4.67:1 and is unchanged.
• Neon: the four band hexes now quantize to distinct green and red xterm entries (addBg #083c10 -> #005f00, delBg #3c0810 -> #5f0000, addBgWord #147828 -> #008700, delBgWord #74202e -> #870000) instead of collapsing to the same grays, while keeping every truecolor invariant green.
• New TestExtendedThemeANSI256Contrast performs the 6x6x6-cube-plus-gray-ramp quantization in the test and asserts the Dune selected-row pairs stay AA and the Neon bands keep green/red identity, mutual distinction, and AA for the primary diff text. One documented limit: faintest line numbers over Neon's addBg cannot reach 4.5:1 in 256-color, because the darkest green cube entry (#005f00) is already too bright against quantized faintest; a green-identified band and an AA faintest pair are mutually exclusive on the xterm cube, so that pair stays truecolor-only (it still clears 2.9:1 quantized).
• docs/THEMES.md is now linked from the Documentation sections of README.md and README_ZH.md, and the Unreleased changelog inventory says twelve themes and names dune and neon.

go build, go vet, and the tui suite pass locally, except TestAltScreenTranscriptScrollKeepsFooterFixed, which fails on this branch without these changes and passes on current main (stale-branch artifact).

[jatmn]

I found issues that need to be addressed before this is ready.

Findings

• [P2] Keep Neon diff text readable after ANSI-256 conversion
  internal/tui/theme_select_test.go:454-464
  The new test deliberately omits two rendered pairs even though the changelog says the presets are audited after xterm-256 downsampling. addLineNum renders faintest on addBg, which quantizes to #5faf5f on #005f00 (2.95:1); highlighted added spans render addInk on addBgWord, which quantizes to #d7ffd7 on #008700 (4.29:1). Thus ordinary 256-colour terminals receive sub-AA added-diff content while this suite remains green. Choose ANSI-safe tokens/backgrounds and assert both actual renderer pairs.

• [P2] Make Neon error-card borders distinguishable from the panel
  internal/tui/theme_palettes.go:364
cardErr is used as the border for renderErrorRow and failed specialist/tool cards, but #8a2f42 has only 2.43:1 contrast against Neon's #050b06 panel, below the 3:1 non-text UI-component threshold. Error boxes therefore blend into the surrounding terminal even though their text is red. Use a sufficiently separated error-border token and cover the rendered border surface.

• [P3] Make the documented palette-extension checks match the documented contract
  docs/THEMES.md:23-31
  The guide says that adding a palette plus a registry entry needs no other work and that new palettes clear the WCAG invariants asserted against the whole registry. However, TestExtendedThemeContrastInvariants intentionally skips every registry entry except these two, so a future palette following the guide can pass CI while its permission, selected-row, and diff-gutter surfaces are unreadable. Either apply those rendered-surface checks to all entries or narrow the extension instructions and require palette-specific coverage.

[euxaristia]

Pushed a fix for all three findings.

• Neon diff content in 256 color: rather than accepting the documented omission, faintest moves to #74c468, which quantizes to #87d75f and clears AA on the xterm-green addBg at 4.52:1 (the old token quantized to 2.95:1), while staying dimmer than faint so the gray-ramp invariant holds. addInk moves to #ecffdc, quantizing to #ffffd7 for 4.60:1 on the word band's #008700. TestExtendedThemeANSI256Contrast now asserts both rendered pairs (line numbers on the row bands, changed-span ink on the word bands) for add and del, and the omission comment is gone.
• Error borders: cardErr moves to #9a4042, 3.01:1 against the panel in truecolor and 3.65:1 quantized, and the border surface is asserted at the 3:1 non-text threshold in both renderings.
• docs/THEMES.md now states the real contract: the registry-wide tests cover the basic text tokens, ramp order, word spans, and selected-row band for every entry, while the extended rendered-surface and ANSI-256 invariants are per-palette, so a new theme must be added to those tests or given equivalent coverage.

go build, go vet, and the theme test suite pass locally.