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/hypr/input.lua

@@ -21,10 +21,18 @@ hl.config({
         repeat_delay = prefs.get("keyRepeatDelay", 500),
         repeat_rate  = prefs.get("keyRepeatRate", 33),
 
-        -- 1 = click to focus. GNOME's behaviour; NOT sloppy focus.
+        -- 1 = FOLLOW. The window under the pointer takes focus. This comment
+        -- previously claimed 1 was "click to focus, GNOME's behaviour", which
+        -- is the opposite of what Hyprland does -- `hyprctl descriptions` gives
+        -- map: [{"separate":3},{"detached":2},{"follow":1},{"disabled":0}],
+        -- so click-to-focus is 0. Changing the shipped value is a behaviour
+        -- decision rather than a correction, so the value is left alone and
+        -- only the description is fixed; Settings exposes all four.
         follow_mouse = prefs.getInt("followMouse", 1),
 
-        -- Don't refocus on mouse move alone -- only on click.
+        -- Softens follow_mouse: with this off, focus changes only when the
+        -- pointer crosses a window boundary, not on every movement inside one.
+        -- Still focus-follows-pointer, just less twitchy.
         mouse_refocus = false,
 
         -- Flat pointer response, no acceleration. Matters for gaming.