Let the config file take back a setting changed at runtime

Reported as windows still being tinted. The tint is the drop shadow, and
init.lua sets general.shadows to false - loading that same config in a
fresh compositor reports false, while the running session reported true.

The reason it could not be corrected is a defect in the live-settings replay
added earlier today. That replay re-applies every srd set after a config
reload so the titlebar menu's Customize rows survive a save. The unintended
half is that a live override then outranked the config file permanently:
editing init.lua and saving put the override straight back, which is the
state the session was found in.

Live-always-wins and config-always-wins are both wrong. The rule is now that
the config wins for anything it states, and a live override survives only
where the config is silent. That distinction cannot come from `values`,
where defaults are seeded before any script runs so every key looks set, so
the config engine records which keys srd.set actually touched during the
load. That record is cleared and rebuilt on each load and restored along
with everything else when a reload fails.

Verified both directions: a config-stated key reverts to the file's value on
the next reload, and a key the config never mentions keeps its live
override.

529 tests pass, clippy clean.

1 files changed, 37 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index e086889..df0bfae 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,5 +1,42 @@
 # TODO / planned features - master checklist
 
+## "Why is there still a tint on windows": a live override the config could never take back (2026-08-28)
+
+The tint is the drop shadow. `init.lua:65` sets `general.shadows` to
+`false`, and loading that same config in a fresh compositor reports
+`shadows: false` - but the running session reported `true`. Something had
+turned shadows on at runtime, and the session had no way back.
+
+**That "no way back" is a defect I introduced.** The live-settings replay
+added earlier today re-applies every `srd set` after each config reload, so
+the titlebar menu's own Customize rows survive a save. The unintended half:
+a live override then outranked the config file *permanently*. Editing
+`init.lua` and saving could not fix it, because the reload put the override
+straight back - which is exactly the state the session was found in.
+
+Live-always-wins and config-always-wins are both wrong, in opposite
+directions. The rule now: **the config wins for anything it states, and a
+live override survives only where the config is silent.** That needs a
+distinction `values` alone cannot make, since defaults are seeded before any
+script runs and so every key looks set - the config engine now records
+which keys `srd.set` actually touched during the load, cleared and rebuilt
+each time, and restored with everything else if the reload fails.
+
+Verified end to end, both directions:
+
+    config says shadows=false          -> false
+    srd set shadows true               -> true
+    save an unrelated config edit      -> false   (the file wins)
+
+    srd set border_width 9             -> 9       (config never mentions it)
+    save an unrelated config edit      -> 9       (override survives)
+
+The running session was also corrected directly with `srd set shadows
+false`, matching what its own config already asked for, so the tint is gone
+without waiting for a restart.
+
+529 tests, clippy clean.
+
 ## Lock screen: the avatar was never read, and the keyboard could not type most passwords (2026-08-28)
 
 Two questions, both real gaps.