Fix focus-mode labels that said the opposite of what they did

Found by codex's GNOME Tweaks audit and verified against the compositor:
`hyprctl descriptions` publishes input:follow_mouse as
map: [{"separate":3},{"detached":2},{"follow":1},{"disabled":0}].

Panama labelled 0 "Never", 1 "Click to focus", 2 "Sloppy focus". So this
desktop, sitting on the shipped value of 1, has been running
focus-follows-pointer the whole time while Settings called it "Click to
focus" -- and the way to actually GET click-to-focus was to choose
"Never". Value 3 was not offered at all. hypr/input.lua carried the same
wrong claim in a comment.

The shipped VALUE is left alone. Which focus mode this desktop should
use is a behaviour decision rather than a correction, and all four are
now reachable from Settings.

Nothing could have caught this. The compositor accepts 1, reads back 1,
and the write contract passes: the value is valid, it just means
something other than the label. The only authority on what each number
MEANS is the compositor, and it publishes that. So enum-hypr-map-contract
now checks every compositor-backed enum against the published map --
that offered values exist, and that published values are offered, since
a missing one is a capability nobody can reach.

Writing it immediately found two more of the same: variable refresh rate
offered Off and fullscreen-games while the compositor publishes four
(always-on and fullscreen-only were unreachable, and fullscreen-only is
what someone wanting VRR for video rather than games wants), and direct
scanout was missing its always-on value. Both now offer everything, with
a detail line per option rather than a bare word.

Verified the contract catches the original followMouse gap and a value
outside the map.

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

config/dot/quickshell/config/PreferenceSchema.qml

@@ -128,10 +128,21 @@ Singleton {
         {
             key: "vrrPolicy", type: "enum", def: 3, group: "display",
             label: "Variable refresh rate",
-            detail: "Content-aware matches the display to what is on screen",
+            detail: "Matches the display's refresh rate to what is on screen",
+            // All four the compositor publishes, rather than the two that were
+            // here. Always-on VRR is a legitimate choice on a panel that
+            // handles it well, and it was simply unreachable -- as was
+            // fullscreen-only, which is what someone wanting VRR for video
+            // rather than games wants.
             options: [
-                { value: 0, label: "Off" },
-                { value: 3, label: "Content-aware" }
+                { value: 0, label: "Off",
+                  detail: "The display runs at a fixed refresh rate" },
+                { value: 1, label: "Always on",
+                  detail: "Best on panels that handle low refresh rates without flicker" },
+                { value: 2, label: "Fullscreen only",
+                  detail: "Any fullscreen window, including video" },
+                { value: 3, label: "Fullscreen games",
+                  detail: "Only fullscreen games, which is the safest default" }
             ],
             hypr: { path: ["misc", "vrr"], option: "misc:vrr", readAs: "int" }
         },
@@ -140,8 +151,12 @@ Singleton {
             label: "Direct scanout",
             detail: "Lets fullscreen content bypass compositing",
             options: [
-                { value: 0, label: "Off" },
-                { value: 2, label: "Automatic" }
+                { value: 0, label: "Off",
+                  detail: "Everything goes through the compositor" },
+                { value: 1, label: "Always on",
+                  detail: "Forced rather than decided per surface; can drop frames on some drivers" },
+                { value: 2, label: "Automatic",
+                  detail: "The compositor decides per surface, which is the safe default" }
             ],
             hypr: { path: ["render", "direct_scanout"], option: "render:direct_scanout", readAs: "int" }
         },
@@ -299,12 +314,28 @@ Singleton {
         },
         {
             key: "followMouse", type: "enum", def: 1, group: "input",
-            label: "Focus follows pointer",
-            detail: "Click to focus matches GNOME; sloppy focus follows the pointer",
+            label: "Pointer focus",
+            detail: "What moving the pointer does to which window is focused",
+            // These labels were wrong, and wrong in the worst way: value 1 was
+            // shown as "Click to focus" while Hyprland's 1 means the opposite.
+            // The compositor publishes the authoritative mapping itself --
+            // `hyprctl descriptions` gives
+            //   map: [{"separate":3},{"detached":2},{"follow":1},{"disabled":0}]
+            // -- so a desktop labelled "Click to focus" was in fact following
+            // the pointer, and the way to actually get click-to-focus was to
+            // choose "Never". Value 3 was missing entirely.
+            //
+            // enum-hypr-map-contract now pins every mapped enum against that
+            // published map, so this cannot drift again.
             options: [
-                { value: 0, label: "Never" },
-                { value: 1, label: "Click to focus" },
-                { value: 2, label: "Sloppy focus" }
+                { value: 0, label: "Click to focus",
+                  detail: "Moving the pointer never changes focus" },
+                { value: 1, label: "Focus follows pointer",
+                  detail: "The window under the pointer takes focus as you move" },
+                { value: 2, label: "Pointer detached",
+                  detail: "The pointer highlights windows on its own; clicking moves keyboard focus" },
+                { value: 3, label: "Pointer fully separate",
+                  detail: "Clicking does not move keyboard focus at all" }
             ],
             hypr: { path: ["input", "follow_mouse"], option: "input:follow_mouse", readAs: "int" }
         },