Themes: Accept a dark/light theme table

[masonmcelvain]

• close Extend config file to set dark/light themes #552

Support a [theme] table in config.toml to set dark/light themes:

[theme]
dark = "catppuccin-mocha"
light = "catppuccin-latte"
fallback = "github-dark-default"  # optional

fallback covers sessions where terminal background is unknown, defaulting to dark.

Writing the pair back exposed that the config writer was rewriting more of config.toml than it should, so that is fixed here too.

Changes

Theme selection

• Add src/core/theme/selection.ts: a ThemeSelection is either a theme id or a { dark, light, fallback? } pair, and the module owns reading, comparing, and resolving one against a terminal background.
• Probe the terminal background for a pair the same way auto does.
• --theme <id> overrides a configured pair for one run.
• Picking a theme in the app replaces the pair with that single id. The save-on-quit prompt renders the collapse before anything is written. - Keep the committed selection separate from the id it resolves to: persistence and in-session refresh carry the pair, while extension theme_changed events keep receiving a concrete id.
• Reject a table that sets only one background, names an unknown key, or gives a non-string id, naming the offending file and key path. An unknown id is still tolerated, since an extension may contribute it later.

Config writing

• Rewrite an existing theme in place instead of appending a second definition, including quoted ("theme" = …) and dotted (theme.dark = …) key forms, and drop duplicate definitions rather than leaving them behind.
• Preserve trailing comments on a rewritten line and comments inside a [theme] table; keep a comment attached to the table it documents.
• Collapse a [theme] table to a top-level theme = "…" when a single id replaces the pair, leaving one blank line between the neighbours it separated.
• Write a pair as an inline table when the file has no [theme] section.

QA

Themes used below are interchangeable; any two built-in ids work.

1. A pair follows the terminal. Put a [theme] table in ~/.config/hunk/config.toml with distinguishable dark/light ids, then run hunk diff in a dark terminal and again in a light one. Each should draw its own side.
2. Fallback. Add fallback and run through a host that does not answer the background query (a script-allocated pty, or LazyGit as a pager). The fallback theme should render; remove fallback and dark should.
3. Flag wins. hunk diff --theme github-dark-default with the table still in config should ignore the pair.
4. Collapse on pick. With the table configured, press t, choose a theme, then q. The prompt should show - theme = { dark = "…", light = "…" } / + theme = "…", and saving should leave a top-level theme = "…" with no [theme] table.
5. Nothing else in the file moves. Before step 4, add comments, a [custom_theme] table, and an [extensions] table around the [theme] table. After saving, they should be untouched, with no doubled blank lines, and the file should still parse.
6. Refresh. With a pair configured, press r, then t. One side of the pair should still be active, and quitting should not offer to save a theme change.
7. Bad tables. A table missing light, or with a typo'd key, should exit 1 naming the file and the problem.

[greptile-apps]

PR author is not in the allowed authors list.

[vercel]

@masonmcelvain is attempting to deploy a commit to the Modem Team on Vercel.

A member of the Team first needs to authorize it.

[benvinegar]

Really like the selection vs. resolved theme split here, and the overall behavior makes sense. I found a few things I think we should address before merging:

• This currently conflicts with main, including the packages/hunk move. After resolving the obvious conflicts locally, typechecking still fails because the new ThemeSelection type needs to be carried through the recently added history surfaces.
• The config writer can corrupt valid TOML. For example, ["theme"] is accepted when reading, but saving adds a second top-level theme, leaving the file unparsable. A [theme] example inside a multiline extension string can also be mistaken for the real table and partially deleted.
• Collapsing [theme] still drops some comments, including comments on the table header and inside the table.
• Terminal probing happens before extension-backed repo discovery finalizes the effective config. If that second config resolution introduces an adaptive pair, we can end up using the dark/fallback side in a light terminal.
• Saving a selection over [diff.theme] writes a top-level theme but leaves the command-scoped table in place, so the saved choice is overridden again on the next run.

I'd strongly suggest validating the generated TOML before replacing the config file, and avoiding rewriting theme at all when its semantic value hasn't changed. Tests around quoted headers, multiline strings, command-scoped themes, and extension-discovered repo config would help here.

The feature and core model look good, but I don't think the config-writing path is safe to merge as-is.