Make Panama settings one shared source of truth

Panama had grown into three configuration surfaces that only agreed because
they had been typed to agree: looks.lua hardcoded values, DesktopPreferences
independently defaulted the same values, and SystemSettings replayed them at
startup. Nothing kept them in sync, and the Lua side read no shared state at
all. This lands the first three stages of docs/superpowers/plans/2026-08-17-panama-cohesion.md.

Fix silently failing Hyprland writes. On a Lua-configured Hyprland, hyprctl
keyword refuses the write, prints the refusal to stdout, and still exits 0, so
the HDR, VRR, and direct-scanout toggles persisted their value and reported
success while the compositor never changed. Writes now go through hyprctl eval,
which has the same hazard on syntax and runtime errors, so success is defined
as reading the value back and finding it equal. The existing contract passed
throughout the outage because it re-applied the values already in place; the
new one flips each value to something it does not hold.

Derive preferences from a schema. Every setting used to be restated four times
-- a property alias, a JSON adapter property, a change handler, and a line in
reset -- where omitting any one failed silently. PreferenceSchema.qml is now
the single source, and persistence, validation, reset, and the Hyprland mapping
all derive from it. Unknown keys on disk survive a write so a rollback does not
discard a newer build's settings, and a corrupt file falls back to shipped
defaults. The store moved to ~/.config/panama/settings.json, migrating from the
old state directory without deleting it.

Share that file with Hyprland. prefs.lua reads it at config time with every
shipped literal kept as the fallback, so the config still stands alone. The Lua
is the default, the JSON is the truth, and Settings is the editor. The
compositor-adjustable surface goes from 3 keys to 23.

Also fixes two test-hygiene bugs found by running the suite end to end for the
first time: settings-pages-contract could see the window settings-window-contract
leaves behind, and the new write contract was persisting its deliberately-wrong
values into the user's real store.

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

config/dot/hypr/README.md

@@ -27,6 +27,7 @@ Don't "fix" them.
 | File | Contents |
 |---|---|
 | `hyprland.lua` | Entry point. Each `require()` is its own error scope |
+| `prefs.lua` | Reads the settings file Panama Settings writes. See below |
 | `env.lua` | Environment. Note the uwsm caveat below |
 | `monitors.lua` | DP-2 geometry, scaling, and the HDR decision |
 | `looks.lua` | Colours, blur, glow, shadows, animations, VRR, scanout |
@@ -43,6 +44,46 @@ Validate any change without leaving your session:
 Hyprland --verify-config
 ```
 
+## Settings: one file, both sides
+
+`~/.config/panama/settings.json` is shared with the Quickshell side. The
+relationship is:
+
+- **This config is the default.** Every adjustable value is written
+  `prefs.get("key", <shipped value>)`, so the config still works standalone with
+  no settings file at all.
+- **The JSON is the truth.** Hyprland and Quickshell both read it.
+- **Panama Settings is the editor.** It writes the file *and* applies the change
+  live, so nothing needs a reload and the two sides cannot drift apart.
+
+To add an adjustable setting: add an entry to
+`quickshell/config/PreferenceSchema.qml` with a `hypr` block naming the
+`hl.config` path, then read it here with `prefs.get`. Nothing else is needed —
+persistence, validation, reset, and the live write are all derived from that
+entry.
+
+`prefs.lua` never raises. A missing, empty, truncated, malformed, or
+wrong-typed settings file costs you your customisations and nothing else;
+`tests/hypr/prefs-fallback-contract.sh` pins that, including that Hyprland still
+accepts the config in each of those states.
+
+### Never use `hyprctl keyword`
+
+On a Lua-configured Hyprland it refuses the write, prints
+`keyword can't work with non-legacy parsers` to **stdout**, and still **exits 0**:
+
+```sh
+$ hyprctl getoption decoration:rounding -j     # → "int": 18
+$ hyprctl keyword decoration:rounding 4        # → the refusal above
+$ echo $?                                      # → 0
+$ hyprctl getoption decoration:rounding -j     # → "int": 18, unchanged
+```
+
+Use `hyprctl eval 'hl.config({ ... })'` instead. Note that `eval` *also* exits 0
+on syntax and runtime errors, reporting them as an `error:` line on stdout — so
+for either command, the only trustworthy signal that a write landed is reading
+the value back with `hyprctl getoption`.
+
 ## The look
 
 Tokyo Night Moon, with two accents that come from the tmux theme: