Report whether a listed key binding is actually grabbed

Requested by the AGS session while wiring its launcher to srd keybindings:
without this the launcher would list a shortcut that does nothing and give no
way to tell, which is the same silent-lie class of bug as the rest of the
work today.

The backend is handed one combo list, once, before connecting - X11 turns it
into XGrabKey calls, Wayland into its intercept set. A reload re-registers
the actions but cannot re-register the grabs, so a combination added to the
config since startup is bound as far as the config engine is concerned and
still goes straight to the focused client when pressed. That snapshot is now
recorded on the WindowManager at the exact point it is handed to the
backend, taken once rather than per-arm so the reported set and the grabbed
set cannot drift apart, and each entry in srd keybindings carries a
`grabbed` flag.

Verified live in a nested instance, both states observed: 46 bindings and
46 grabbed at startup; then appending a new combination to the config gave
47 bindings, 46 grabbed, with the new one reported as not grabbed and
carrying its description. Two unit tests cover the set being replaced rather
than accumulated, and a combo outside it reading as not grabbed.

Also recorded, from the AGS session's own checks: moving a window to a
workspace was their bug, not a missing compositor feature - the Overview's
previews had a drop target and the bar's workspace dots had none, so the
gesture worked on one surface and silently did nothing on the other. And the
static half of "are all keybindings working" is clean for the running
session: keybindings.lua was last modified 06:02:55 and the compositor
started 18:11:13, so every combination in it was grabbed at boot.

517 tests pass, clippy clean.

1 files changed, 13 insertions, 4 deletions

diff --git a/docs/DEFAULTS.md b/docs/DEFAULTS.md
index abcdad1..daa65d8 100644
--- a/docs/DEFAULTS.md
+++ b/docs/DEFAULTS.md
@@ -942,9 +942,18 @@ with the window that spawned it.
 description if it gave one:
 
 ```
-{"keybindings":[{"combo":"Mod4+Return","description":"Open a terminal"}, ...]}
+{"keybindings":[{"combo":"Mod4+Return","description":"Open a terminal","grabbed":true}, ...]}
 ```
 
+`grabbed` is `false` when the config binds that combo but the compositor
+does not actually intercept it. The backend is handed one combo list, once,
+before connecting - X11 turns it into `XGrabKey` calls, Wayland into its
+intercept set. A reload re-registers the *actions* but cannot re-register
+the grabs, so a combination added to the config since startup is bound as
+far as the config engine is concerned and still goes straight to the focused
+client when pressed. Anything listing bindings should show that rather than
+offering a shortcut that silently does nothing.
+
 `srd.bind` takes an optional third argument for that description:
 
 ```lua
@@ -955,9 +964,9 @@ Bindings live entirely inside the Lua engine, so before this nothing outside
 the compositor could see that a binding existed at all - a launcher or
 cheat-sheet had no way to show the user their own keys. The list is
 republished after every config reload, so a rebound key appears without a
-restart. Note that a brand new *combination* still needs a restart before the
-compositor grabs that key at all; an existing combination picks up its new
-action immediately.
+restart - with `grabbed: false` until the compositor is restarted, since an
+existing combination picks up its new action immediately but a brand new one
+is not intercepted until the next startup.
 
 Combos are reported in canonical order (`Ctrl+Mod4+l`), which is what the
 compositor matches a real keypress against - not necessarily how the combo