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",

tests/quickshell/settings-ownership-contract.sh

@@ -2,7 +2,9 @@
 
 # A setting has one schema-routed owner. A second page may mirror it only when
 # this contract names the exact owner and mirror set. The same ownership rule
-# keeps colour scheme propagation away from the focused Prism border.
+# says who writes each half of the window border: ColorScheme.qml owns the
+# neutral inactive role AND the accent-derived focused role, restating both
+# together on every scheme or accent change.
 
 set -euo pipefail
 
@@ -124,8 +126,28 @@ if dark.group(1) not in looks or light.group(1) not in looks:
     raise SystemExit("Hyprland startup values disagree with the live scheme roles")
 
 without_comments = re.sub(r"//.*", "", scheme)
-if re.search(r"(?<![A-Za-z_])active_border\b", without_comments):
-    raise SystemExit("ColorScheme writes the focused border")
+
+# The focused border is the accent role, and ColorScheme.qml owns it too:
+# each named accent carries a separate pair per scheme, so a scheme change
+# must restate the focused border, not just the neutral one, or a chosen
+# accent goes stale the moment light/dark flips.
+start = re.search(r'property string accentBorderStart:\s*root\.hyprColor\(Theme\.accent\)', scheme)
+end = re.search(r'property string accentBorderEnd:\s*root\.hyprColor\(Theme\.accentSecondary\)', scheme)
+if not start or not end:
+    raise SystemExit("ColorScheme does not derive the focused border from the chosen accent")
+
+# Written as a Lua TABLE, not a string: the string form of a Hyprland gradient
+# carries only one stop, so writing it that way is accepted and silently
+# keeps whatever the previous accent left behind. Built through the same
+# serialiseValue() SystemSettings.qml uses for every other gradient, rather
+# than a second hand-rolled (and unescaped) copy of that table syntax here.
+if 'SystemSettings.serialiseValue({' not in without_comments:
+    raise SystemExit("ColorScheme does not build the focused border through the shared gradient serialiser")
+if 'colors: [root.accentBorderStart, root.accentBorderEnd]' not in without_comments:
+    raise SystemExit("ColorScheme does not derive the focused-border gradient from the chosen accent")
+if 'active_border = ${activeBorder}' not in without_comments:
+    raise SystemExit("ColorScheme does not write the focused border as the serialised gradient table")
+
 if 'inactive_border = "${root.inactiveBorder}"' not in scheme:
     raise SystemExit("ColorScheme does not apply its effective inactive role")
 PY