Carry the colour scheme into btop and tmux

Two more applications that keep their own palette and so never followed
the desktop. btop was on "Default" and had never been themed at all;
tmux had Tokyo Night Moon hardcoded across seventeen lines, which meant
a dark status bar sitting under a light terminal in light mode.

Both themes are authored rather than borrowed. btop ships a
"tokyo-night" theme, but it is the Night variant (#1a1b26) where the
rest of this desktop is Moon (#222436), and two Tokyo Nights side by
side read as a mistake; it ships no Tokyo Night light theme at all.
Colours come from kitty's theme files so a terminal and what runs inside
it cannot disagree.

tmux follows kitty's shape: the colours move to themes/, tmux.conf
sources a generated current-theme.conf, and running servers are
re-sourced so an open session changes immediately rather than at next
launch. btop is different -- it OWNS btop.conf and rewrites it on exit,
so only the color_theme line is edited in place and the file is not
symlinked into the repository. btop reads its theme once at startup, so
a running instance keeps the old colours; forcing a restart would kill a
process the user is watching.

The tmux light theme took two passes. Mapping the palette role-for-role
put the standard Day accents on a mid-grey panel at 2.74:1 and 2.94:1 --
under the 3:1 floor, on a bar you read at a glance. It now uses Day's
darker accent variants on a lighter panel: 4.42:1 and 4.17:1, and
5.01:1 / 4.73:1 for the light text inside the inverted blocks.

The helper also now reports every target rather than only kitty. Saying
"kitty: applied" while silently skipping three other applications is
how a half-applied theme goes unnoticed.

Not changed: bat is configured with --theme ansi, which follows the
terminal's own palette, so it already tracks kitty with nothing to do.

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

setup/scripts/link-dotfiles

@@ -70,6 +70,45 @@ for dir in "${dirs[@]}"; do
   log "Linked $PANAMA_DOT/$dir → $CONFIG/$dir"
 done
 
+# tmux.conf ends with a source-file of current-theme.conf, generated from the
+# colour scheme rather than committed. Seed it so a fresh checkout starts themed
+# -- the source-file is -q, so a missing file is silent, which would leave tmux
+# unstyled with nothing to explain it.
+TMUX_THEME="$PANAMA_DOT/tmux/current-theme.conf"
+if [ -e "$TMUX_THEME" ]; then
+  log "Keeping existing tmux theme at $TMUX_THEME"
+elif [ -d "$PANAMA_DOT/tmux/themes" ]; then
+  tmux_scheme="dark"
+  tmux_prefs="${XDG_CONFIG_HOME:-$HOME/.config}/panama/settings.json"
+  if [ -r "$tmux_prefs" ]; then
+    tmux_stored="$(jq -r '.colorScheme // "dark"' "$tmux_prefs" 2>/dev/null || echo dark)"
+    [ "$tmux_stored" = "light" ] && tmux_scheme="light"
+  fi
+  [ "$tmux_scheme" = "light" ] && tmux_name="tokyonight-day" || tmux_name="tokyonight-moon"
+  cp "$PANAMA_DOT/tmux/themes/$tmux_name.conf" "$TMUX_THEME"
+  log "Seeded tmux $tmux_scheme theme ($tmux_name) → $TMUX_THEME"
+fi
+
+# btop reads themes from its own config directory, but OWNS btop.conf -- it
+# rewrites that file on exit -- so only the theme files are exposed, per file,
+# and the config itself is left to btop. panama-theme-apps edits the single
+# color_theme line in place.
+BTOP_THEME_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/btop/themes"
+mkdir -p "$BTOP_THEME_DIR"
+for btop_theme_src in "$PANAMA_DOT"/btop/themes/*.theme; do
+  [ -e "$btop_theme_src" ] || continue
+  btop_theme_dst="$BTOP_THEME_DIR/$(basename "$btop_theme_src")"
+  if [ -L "$btop_theme_dst" ]; then
+    rm "$btop_theme_dst"
+  fi
+  if [ -e "$btop_theme_dst" ]; then
+    log "Keeping existing btop theme at $btop_theme_dst"
+  else
+    ln -s "$btop_theme_src" "$btop_theme_dst"
+    log "Linked btop theme → $btop_theme_dst"
+  fi
+done
+
 # GTK3 has no include mechanism, so its settings.ini is generated whole from a
 # template rather than layered. Without this, a fresh checkout has a template
 # and no settings.ini, and GTK3 applications fall back to their built-in theme.