Expose key bindings over IPC so a launcher can list them

Asked whether srdwm's bindings show in the AGS launcher. They could not:
srd.bind lives entirely in the Lua engine, and nothing published a binding
anywhere a client could read it. There was no IPC command, no field in any
response, and bound_keys() was used only by main.rs to register grabs.

srd.bind now takes an optional third argument, a description, and the loaded
set is copied into the WindowManager after the initial load and after every
reload. Core neither owns nor interprets them - it has no Lua state and
never dispatches a key - it holds them so the IPC layer, which is handed a
WindowManager and nothing else, can serve them. New `srd keybindings` returns
combo and description pairs, sorted so a UI listing them does not reshuffle
on every refresh.

Every binding in the shipped config now carries a description, so the feature
is useful without the user writing any.

Verified live in a nested instance: 46 bindings published, 0 without a
description, and editing the config file updated the list without a restart
(which also exercised reload-on-write again).

Also verified, for the separate report that windows cannot be moved to
another workspace from the AGS workspace pills: the compositor side works.
`srd dispatch move workspace <id> 2` moved a window from workspace 1 to 2 and
correctly hid it, since workspace 1 was active. Nothing to fix here; the
missing piece is on the shell side.

515 tests pass, clippy clean.

1 files changed, 27 insertions, 0 deletions

diff --git a/docs/DEFAULTS.md b/docs/DEFAULTS.md
index 2cc1614..abcdad1 100644
--- a/docs/DEFAULTS.md
+++ b/docs/DEFAULTS.md
@@ -935,3 +935,30 @@ make an app forget where it lives.
 Dialogs are centred instead, and take neither a remembered position nor a
 remembered size - window memory is keyed by `app_id`, which a dialog shares
 with the window that spawned it.
+
+## Listing key bindings
+
+`srd keybindings` returns every binding the loaded config registered, with a
+description if it gave one:
+
+```
+{"keybindings":[{"combo":"Mod4+Return","description":"Open a terminal"}, ...]}
+```
+
+`srd.bind` takes an optional third argument for that description:
+
+```lua
+srd.bind("Mod4+Return", function() srd.spawn("alacritty") end, "Open a terminal")
+```
+
+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.
+
+Combos are reported in canonical order (`Ctrl+Mod4+l`), which is what the
+compositor matches a real keypress against - not necessarily how the combo
+was written in the config.