Finish threading the accent colour through the whole desktop

The recent accent-colour setting only reached part of the desktop.
looks.lua still hardcoded the focused-window border and glow to blue,
so any hyprctl reload -- or every fresh session, for about a second --
reverted a chosen accent; it now reads accentName the same way it
already read colorScheme. The lock screen and terminal stayed blue
regardless of the chosen accent despite the setting's own description
claiming otherwise; panama-lock and panama-theme-apps now resolve and
apply the real accent.

AccentPicker built its swatch model from Theme.accents directly
instead of the schema's own options list, so the two could drift
silently; switched it to read the schema. Its hit target only covered
the swatch, not the name label added specifically for colour-vision
accessibility -- extended to the whole row. Settings search had no
route for the "appearance" group, so searching for the accent or
colour scheme landed on Home.

ColorScheme's hex-to-Hyprland helper assumed 6-digit colours and would
silently corrupt a future translucent one; fixed it to read from the
end of the string instead of the start. An accent-only change no
longer reruns the full colour-scheme pipeline. The gradient it builds
for the focused border now goes through SystemSettings' existing
serialiser instead of a second, under-escaped copy of the same logic.

The settings-ownership contract test enforced the old rule that
ColorScheme must never touch the focused border; updated it to verify
the real, intended rule instead of contradicting the code.

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

tests/quickshell/lock-screen-helper-contract.sh

@@ -69,7 +69,7 @@ assert_schema_entry() {
 }
 
 [[ -x "$helper" ]] || fail 'panama-lock helper is missing or not executable'
-for key in lockBackgroundMode lockBlurLevel lockShowClock lockShowDate lockShowUser lockFadeOnEmpty; do
+for key in lockBackgroundMode lockBlurLevel lockShowClock lockShowDate lockShowUser lockFadeOnEmpty accentName; do
     assert_schema_entry "$key"
 done
 
@@ -112,6 +112,25 @@ if rg -q '^label \{' "$generated"; then
     fail 'hidden clock, date, and user labels were still generated'
 fi
 
+# ── The focus ring follows the chosen accent, not just the scheme ───────────
+# A pinned blue literal only ever proves the DEFAULT accent renders correctly,
+# not that the helper actually reads accentName. Orchid is picked because its
+# hex is nowhere close to blue's in either scheme, so a helper that quietly
+# ignored accentName and kept emitting blue would be caught here.
+write_settings '{"accentName":"orchid","colorScheme":"dark"}'
+run_helper generate
+rg -Fq 'outer_color = rgba(192, 153, 255, 0.9)' "$generated" || fail 'dark orchid accent did not drive the focus ring'
+rg -Fq 'check_color = rgba(192, 153, 255, 1.0)' "$generated" || fail 'dark orchid accent did not drive the success colour'
+
+write_settings '{"accentName":"orchid","colorScheme":"light"}'
+run_helper generate
+rg -Fq 'outer_color = rgba(120, 71, 189, 0.9)' "$generated" || fail 'light orchid accent did not drive the focus ring'
+rg -Fq 'check_color = rgba(120, 71, 189, 1.0)' "$generated" || fail 'light orchid accent did not drive the success colour'
+
+write_settings '{"accentName":"not-a-real-accent","colorScheme":"dark"}'
+run_helper generate
+rg -Fq 'outer_color = rgba(130, 170, 255, 0.9)' "$generated" || fail 'an unknown accent name did not fall back to blue'
+
 write_settings '{
   "lockBackgroundMode":"wallpaper",
   "wallpaperMode":"per-monitor",