Fix dark mode: the GTK theme it asked for does not exist

Reported symptom: Electron applications and a Chromium-based browser,
all set to follow the system, went light when the desktop went light and
never came back. Nothing reported an error, and the portal was serving
the correct value the whole time.

Cause: ColorScheme set gtk-theme to "Adwaita-dark" for dark and
"Adwaita" for light. Neither is installed on Fedora 44 -- only adw-gtk3
and adw-gtk3-dark are. GTK responds to an unknown theme name by falling
back to its built-in default, which is LIGHT. So asking for light worked
by accident, asking for dark silently produced light, and anything that
takes its cue from the GTK theme rather than the portal stayed light no
matter what org.freedesktop.appearance said. Verified: the portal emits
correctly in both directions, so this was never the portal's fault.

Second cause, the mirror of the first: gtk-3.0/settings.ini and
gtk-4.0/settings.ini were pinned to adw-gtk3-dark and prefer-dark=1 and
never regenerated. Under GNOME that file is ignored because
gnome-settings-daemon publishes over XSETTINGS; under Hyprland nothing
does, so for GTK3 it is authoritative -- and it contradicted the scheme
in light mode. They are now generated from a template on every switch,
gitignored as machine state, and seeded by link-dotfiles, the same shape
kitty's current-theme.conf already uses. These directories are symlinked
into the repository, so writing the live file directly would dirty the
working tree on every theme switch.

The failure was silent by construction, so it gets a test rather than a
comment: gtk-theme-contract asserts every theme name Panama sets is
actually installed, and that the generated GTK config agrees with the
scheme in both directions. Verified it catches both original bugs.

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

setup/scripts/link-dotfiles

@@ -70,6 +70,34 @@ for dir in "${dirs[@]}"; do
   log "Linked $PANAMA_DOT/$dir → $CONFIG/$dir"
 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.
+# panama-theme-apps rewrites both files on every scheme change after this.
+for gtk_version in 3.0 4.0; do
+  gtk_template="$PANAMA_DOT/gtk-$gtk_version/settings.ini.template"
+  gtk_settings="$PANAMA_DOT/gtk-$gtk_version/settings.ini"
+  [ -r "$gtk_template" ] || continue
+  if [ -e "$gtk_settings" ]; then
+    log "Keeping existing GTK settings at $gtk_settings"
+  else
+    gtk_scheme="dark"
+    gtk_prefs="${XDG_CONFIG_HOME:-$HOME/.config}/panama/settings.json"
+    if [ -r "$gtk_prefs" ]; then
+      gtk_stored="$(jq -r '.colorScheme // "dark"' "$gtk_prefs" 2>/dev/null || echo dark)"
+      [ "$gtk_stored" = "light" ] && gtk_scheme="light"
+    fi
+    if [ "$gtk_scheme" = "light" ]; then
+      gtk_name="adw-gtk3"; gtk_dark=0
+    else
+      gtk_name="adw-gtk3-dark"; gtk_dark=1
+    fi
+    sed -e "s/@GTK_THEME@/$gtk_name/" -e "s/@PREFER_DARK@/$gtk_dark/" \
+      "$gtk_template" > "$gtk_settings"
+    log "Generated GTK $gtk_version settings ($gtk_name) → $gtk_settings"
+  fi
+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