fix: regenerate gtk.css/vicinae.toml on every theme switch

[Krixam]

Problem

omarchy-hook runs every script in a hook's .d/ directory twice:
once through the theme-set wrapper (which exports the color vars like
$primary_background, $normal_red, etc.), and once again directly by
its own loop, without those vars set (see /usr/share/omarchy/bin/omarchy-hook).

10-gtk.sh and 10-vicinae.sh guarded against that double-run by only
writing their output if [ ! -f "$output_file" ] (skip if it already
exists). That avoids the var-less second pass clobbering the good first
pass, but as a side effect it also permanently blocks regeneration on
every subsequent theme switch, since the output path
(~/.config/omarchy/current/theme/...) is fixed and reused across themes.

Worse: if either script's very first run ever happened before real color
vars were available (e.g. before colors.toml existed at its current
Omarchy 3.3+ path), it bakes in empty colors permanently — producing
invalid CSS like @define-color window_bg_color #;. GTK treats that as
"no background", so GTK4/libadwaita apps (Nautilus, GNOME Disks, etc.)
render fully transparent, showing the desktop through them — and no
later theme switch ever fixes it, because the file already exists.

Fix

Guard on [ -n "$primary_background" ] instead of file existence:
regenerate whenever real color data is actually present (every proper
pass, every theme switch), and no-op on the var-less second pass so it
leaves the good output from the first pass alone.

Testing

Reproduced on a live Omarchy install where gtk.css/vicinae.toml had
been stuck with empty colors since a very early hook run, surviving many
theme switches. Applied this fix, then switched themes back and forth
(e.g. Nord → Ristretto) and confirmed gtk.css and vicinae.toml
correctly picked up each theme's real colors every time, with no
regression from the double-invocation.