Carry the colour scheme into terminals and the editor

The scheme switch already reached everything that reads
org.freedesktop.appearance -- GTK4, Qt6, Chromium, Electron -- because
ColorScheme.qml writes the gsettings key those all watch. Applications
carrying their own palettes did not follow, so choosing light mode left
the two windows actually used all day, kitty and neovim, still dark.

kitty: the 32 colours move out of kitty.conf into themes/, and kitty.conf
ends with `include current-theme.conf`. The generated file is machine
state rather than configuration, so it is gitignored and link-dotfiles
seeds it on install -- otherwise a fresh checkout starts by complaining
about a missing include. Running terminals are re-coloured in place over
their control sockets; a restart is not needed.

neovim: reads settings.json directly, since it neither watches the portal
nor keeps a socket open. Tokyo Night ships Day in the same family as
Moon, so light mode keeps the editor's identity instead of turning it
into a different-looking application. The existing readability overrides
were written against Moon and are now dark-only -- applied to Day they
would have put light grey on a light background, the same problem they
exist to fix, inverted. Light mode gets one override of its own:
tokyonight's shipped comment colour measures 2.54:1 against Day's
background, under the 3:1 floor for secondary text, so it is replaced
with 3.25:1 -- readable, still dimmer than Normal's 4.52:1.

An editor already open when the scheme flips re-applies on FocusGained,
which is cheap and fires exactly when the mismatch would be noticed.

Verified both directions: kitty re-coloured 4 live terminals, and neovim
starts as tokyonight-day with background=light and tokyonight-moon with
background=dark.

Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L

setup/scripts/link-dotfiles

@@ -70,6 +70,27 @@ for dir in "${dirs[@]}"; do
   log "Linked $PANAMA_DOT/$dir → $CONFIG/$dir"
 done
 
+# kitty.conf ends with `include current-theme.conf`, and that file is generated
+# from the desktop colour scheme rather than committed -- it is machine state.
+# A fresh checkout therefore has no such file, and kitty starts by complaining
+# about a missing include and falling back to its stock colours. Seed it from
+# the scheme in settings.json (dark unless the user has chosen otherwise) so a
+# first launch is themed; ColorScheme.qml overwrites it on every change after.
+KITTY_THEME="$PANAMA_DOT/kitty/current-theme.conf"
+if [ -e "$KITTY_THEME" ]; then
+  log "Keeping existing kitty theme at $KITTY_THEME"
+else
+  scheme="dark"
+  settings="${XDG_CONFIG_HOME:-$HOME/.config}/panama/settings.json"
+  if [ -r "$settings" ]; then
+    stored="$(jq -r '.colorScheme // "dark"' "$settings" 2>/dev/null || echo dark)"
+    [ "$stored" = "light" ] && scheme="light"
+  fi
+  [ "$scheme" = "light" ] && theme="tokyonight-day" || theme="tokyonight-moon"
+  cp "$PANAMA_DOT/kitty/themes/$theme.conf" "$KITTY_THEME"
+  log "Seeded kitty $scheme theme ($theme) → $KITTY_THEME"
+fi
+
 # Vicinae 0.26 discovers user themes from its XDG data directory rather than
 # from ~/.config/vicinae. Keep the authored theme in Panama with the rest of
 # the launcher config and expose only that file at Vicinae's runtime path.