refactor: build the shortcut overview from AdwShortcutsDialog

The hand-rolled grid existed to avoid GTK's deprecated GtkShortcutsWindow;
libadwaita 1.8's AdwShortcutsDialog is the supported replacement, so use the
platform widget and get its search, sectioning and shortcut labels for free.

The table strings become GTK accelerator syntax, since the shortcut label parses
them. The six mouse rows cannot: no accelerator syntax names a wheel or a drag,
so they carry an empty accelerator and prose in the new subtitle field.

adw_init() is called in run_ui() and in choose_source() (replacing its
gtk_init()), which means the whole app is drawn with libadwaita's stylesheet.
Verified settled: viewport.w 870..870, axes.w changes 2, x-desync 0.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

CLAUDE.md

@@ -24,6 +24,18 @@ form for a new host. Every probe below passes `--server`, so none of them sees i
 (`PLOT_BUILD_GTK4`); its tests and examples are forced off. `deps/udpsclient` is a
 vendored C99 source pair compiled into a static lib.
 
+**libadwaita ≥ 1.8 is a system dependency** (`pkg_check_modules(ADWAITA ... libadwaita-1>=1.8)`),
+for exactly one widget: the shortcut overview is an `AdwShortcutsDialog`. GTK4's own
+`GtkShortcutsWindow` is deprecated as of 4.18 and that is its replacement. Two consequences
+worth knowing before editing. `adw_init()` is called — in `run_ui()` and, since the chooser
+runs first and must be styled the same, in `choose_source()` in place of its `gtk_init()`
+(both are idempotent) — so **the whole app is drawn with libadwaita's stylesheet**, not
+GTK's: a metric change there reaches every widget, and `layout over N frames` /
+`axes.w changes` is what says whether the layout still settles. And an `AdwDialog` is
+**not** a `GtkWindow`: `show_shortcuts()` keeps an `AdwDialog*`, clears it on `::closed`
+(there is no `::close-request`) and closes it with `adw_dialog_close()`. Presenting it on
+this app's plain `GtkApplicationWindow` is supported and warning-free; it was checked.
+
 `deps/plotter` is upstream's own repository and this app's figure support was added
 there rather than worked around here: `Figure::set_min_y_gutter()` (a floor under the
 common left gutter), and in the GTK4 adapter `PlotArea`'s **figure mode** —
@@ -1253,6 +1265,16 @@ far the largest file.
   `gtk_icon_theme_has_icon()` is checked for every toolbar button and reported by the dump (see
   `toolbar icons:` under Verification): a resource path that was never added does not raise an
   error, it draws `image-missing`.
+- **A shortcut table row's `accel` is GTK accelerator syntax, and a pointer gesture has
+  none.** `src/shortcuts.cpp`'s strings are handed to `AdwShortcutsItem`, which parses them
+  with `gtk_accelerator_parse()` — so they are `"space"`, `"<Control>e"`, `"<Control>slash"`,
+  `"plus minus"` (a space-separated pair is the "either of these" form the label draws as
+  `+ / -`), never the prose `"Ctrl+E"` or `"+ / -"`. Neither GTK's syntax nor libadwaita's
+  knows a **wheel or a drag**: `"Wheel"` costs a `Failed to parse` warning and draws an empty
+  cell. Those six rows therefore carry `accel = ""` and put the prose in `subtitle`, which is
+  the one field that is free text. A row added with a parse error is otherwise silent — the
+  overview still opens and the row is simply blank — so read the probe run's stderr for
+  `Failed to parse` after touching either table.
 - **The chooser runs before `ScopeModel` exists, and `--server` is what decides.** `Config` carries
   `server_specified`, set only by the `--server` branch, and `main()` asks only when it is false —
   so declining costs no buffer and no socket, and `ScopeModel`, `Acquisition`, `RowSet` and