feat(shortcuts): tell the key story once, and give the arrows back

Decision 1 keeps the unmodified single-key bindings, and Settings was
the only place they were written down — three of the four categories of
them, because config-page listed the categories by hand, so the autotag
keys were written down nowhere at all. `?` now opens an overlay from
anywhere the app owns the keyboard, and both surfaces read one table
(services/shortcut-meta.ts, moved out of config-page's private static).

The other half is the same explanation from the other side. Phase 1
gave the arrow keys to the grid, correctly — but all six of them, and
no list in this app moves horizontally: track-list's own handler and
utils/roving-rows both take Up/Down/Home/End and ignore Left/Right. So
seeking stopped working from a focused row and nothing gained the keys.
Reproduced in the running app: two ArrowRights on a focused track row,
zero Player.Seek calls, against one per press from the body.

A shifted character no longer reports Shift, so the binding is `?` and
not `Shift+?` — the character already carries the shift, and a layout
where it does not is a layout where "Shift+?" is wrong anyway.

e2e/specs/player-truth.spec.ts

@@ -77,9 +77,12 @@ async function readClocks(
  * Move focus off the track row.
  *
  * Phase 1 made rows a real grid with roving tabindex, and global
- * single-key bindings yield to a focused control that owns the key —
- * so with a row focused the arrows navigate the list rather than
- * seeking, which is correct and is not what this spec is about.
+ * single-key bindings yield to a focused control that owns the key.
+ * A row owns the *vertical* arrows only now (Phase 5), so Left/Right
+ * seek from a focused row too and this is no longer load-bearing — it
+ * stays because this spec is about the clock, not about scope
+ * resolution, and it should keep measuring the same thing if that
+ * rule changes again.
  */
 async function blurDeepActive(app: Page): Promise<void> {
   await app.evaluate(() => {