kitty gives *-theme.auto.conf priority over everything -- includes and
even --override -- and has no option to stop following the OS. So the
only way to start in a chosen mode is to control what those files
contain. Make them generated:
themes/{light,dark,no-preference}.conf canonical, the real themes
theme-mode auto | light | dark
apply-theme-mode.sh writes the three .auto.conf
Under `auto` each appearance keeps its own theme, so kitty follows the
OS as before. Pinned, all three get the pinned theme, so kitty starts in
it whatever the OS says and a config reload no longer resets it.
`theme` now records the mode and reloads instead of calling set-colors,
which is why the setting survives restarts. A bare `theme` records
`auto` rather than pinning when the toggle lands on the macOS
appearance, so nothing is pinned unless it actually differs.
The kitten shim hashes the automatic theme files before running `kitten
themes` and copies whichever changed into themes/, so picking a new
light theme while pinned to dark is kept and applied on the next switch.
Covered by tests/test_theme_mode.sh.
conf.d/kitty_theme.fish is gone: theme-mode is now the source of truth,
so the universal-variable tracker it maintained is redundant.
`theme` switches kitty between the existing dark-theme.auto.conf and
light-theme.auto.conf via `kitty @ set-colors --all --configured`, so it
stays in sync with whatever `kitten themes --light/--dark` selects.
Subcommands: light, dark, auto (hand control back to the OS appearance
via load-config), status.
Tide is resynced by calling __tide_apply_terminal_appearance directly,
so the prompt recolors even if kitty sends no palette-change
notification for a dynamic color change. conf.d/kitty_theme.fish tracks
$fish_terminal_color_theme into $kitty_theme_mode so the toggle still
reads the real state after kitty follows an OS appearance change.
light-theme.auto.conf had no tab colors, which left the dark tab bar on
a light background after switching; add a matching tab style block.
