Make the lock screen follow the colour scheme

hyprlock.conf shipped with Tokyo Night Moon hardcoded in six places, so
choosing light mode left the lock screen dark. Every other surface had
been taught to follow the scheme this week -- kitty, GTK, the launcher,
btop, tmux, neovim -- and this was the one left, which is unfortunate,
because it is the screen a user sees most often and the worst possible
place to find a theming bug: you discover it while locked out of the
machine and cannot fix it from there.

It is now generated from a template on every scheme change, the same
shape kitty, GTK, tmux and btop already use, and seeded by link-dotfiles
so the first lock of a fresh install is themed rather than falling back
to hyprlock's bare grey default. hyprlock is launched fresh on each lock
(`pidof hyprlock || hyprlock`), so it picks the file up with no restart.

The dark output is byte-identical to the file it replaces, ignoring
comments -- verified by diff -- so nothing changes for anyone already in
dark mode.

One detail worth recording: hyprlock takes rgba(r, g, b, a) in DECIMAL,
not hex, so the template carries "R, G, B" triples where every other
theme file in this repository uses hex. Two values are the exception,
sitting inside Pango markup where hyprlock wants ##rrggbb. Getting
either wrong is not a parse error -- hyprlock ignores the value and uses
its own default, silently.

Which is why this has a contract. It generates both schemes into a
fixture, never the live config, and checks that no placeholder survives
substitution, that every colour is a well-formed decimal triple, that
the Pango values are well-formed hex, that a light lock screen is
actually light, and that the two schemes differ at all. Verified it
catches a hardcoded colour left in the template and a light mode built
from the dark palette, which is the original bug exactly.

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

setup/scripts/link-dotfiles

@@ -89,6 +89,38 @@ elif [ -d "$PANAMA_DOT/tmux/themes" ]; then
   log "Seeded tmux $tmux_scheme theme ($tmux_name) → $TMUX_THEME"
 fi
 
+# hyprlock.conf is generated from a template on every colour scheme change and
+# is not committed. Seed it so the FIRST lock of a fresh install is themed --
+# without it hyprlock falls back to its own defaults, which is a bare grey
+# screen with none of this desktop's identity, and the first time anyone would
+# find out is when they walked away from the machine.
+HYPRLOCK_TEMPLATE="$PANAMA_DOT/hypr/hyprlock.conf.template"
+HYPRLOCK_CONF="$PANAMA_DOT/hypr/hyprlock.conf"
+if [ -e "$HYPRLOCK_CONF" ]; then
+  log "Keeping existing hyprlock config at $HYPRLOCK_CONF"
+elif [ -r "$HYPRLOCK_TEMPLATE" ]; then
+  lock_scheme="dark"
+  lock_prefs="${XDG_CONFIG_HOME:-$HOME/.config}/panama/settings.json"
+  if [ -r "$lock_prefs" ]; then
+    lock_stored="$(jq -r '.colorScheme // "dark"' "$lock_prefs" 2>/dev/null || echo dark)"
+    [ "$lock_stored" = "light" ] && lock_scheme="light"
+  fi
+  if [ "$lock_scheme" = "light" ]; then
+    sed -e "s/@FG@/55, 96, 191/g"     -e "s/@MUTED@/97, 114, 176/g" \
+        -e "s/@ACCENT@/46, 125, 233/g" -e "s/@ERROR@/245, 42, 101/g" \
+        -e "s/@BG@/225, 226, 231/g"    -e "s/@FIELD@/208, 213, 227/g" \
+        -e "s/@MUTED_HEX@/6172b0/g"    -e "s/@ERROR_HEX@/f52a65/g" \
+        "$HYPRLOCK_TEMPLATE" > "$HYPRLOCK_CONF"
+  else
+    sed -e "s/@FG@/200, 211, 245/g"   -e "s/@MUTED@/130, 139, 184/g" \
+        -e "s/@ACCENT@/130, 170, 255/g" -e "s/@ERROR@/255, 117, 127/g" \
+        -e "s/@BG@/34, 36, 54/g"        -e "s/@FIELD@/46, 47, 61/g" \
+        -e "s/@MUTED_HEX@/828bb8/g"     -e "s/@ERROR_HEX@/ff757f/g" \
+        "$HYPRLOCK_TEMPLATE" > "$HYPRLOCK_CONF"
+  fi
+  log "Seeded hyprlock $lock_scheme theme → $HYPRLOCK_CONF"
+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