The board's keyboard can do what the terminal's already does: add, edit, delete and filter without a mouse #109

Give the web board the keyboard the terminal already has: add, edit, delete and filter without reaching for the mouse.

What it is like today. static/board.822340210.js binds exactly one keydown handler (line 225) and it handles four keys — the arrows, on a focused card. static/theme.1025564933.js adds ?. That is the whole keyboard surface of the page. The same board over ssh (src/keys.ts) gives a person a add card, e edit, d delete, J/K/H/L move, c new column, r rename, D delete column, [ ] reorder, f filter, u undo. AGENTS.md asks that what a person can do on the page they can do in the terminal; here it is the other way round, and the direction's first line is "keyboard first, drag and drop second".

#69 rebuilds how focus moves across a full board (roving tabindex). This is the other half: what the keys do once focus is there.

Done looks like

• [ ] With a card focused: Enter starts editing its title (focus the existing inline input; Escape restores the old title and returns focus to the card), Delete or Backspace deletes it through the same request the ✕ button makes, Home / End move it to the top / bottom of its column in one press.
• [ ] From anywhere on the board when focus is not in a field: / focuses the filter, Escape in the filter clears it and returns focus to the board, n focuses the "New card" input of the focused card's column (or the first column when nothing is focused).
• [ ] Every key is guarded exactly like the existing ?: it does nothing when focus is inside an input, textarea or select, and it only calls preventDefault when it acted — Backspace must never swallow a browser back that the page did not handle.
• [ ] Undo is deliberately not bound to a key here: on a shared board a blind undo is what #43 and #93 are still fixing. Say that in the pull.
• [ ] Every write goes through the existing handlers, so optimistic update, toast on refusal and the live event are unchanged — no new fetch call sites.
• [ ] The ? dialog lists them (boardShortcuts in src/pages/board.ts) and the README's "Using it" gains the same short table.
• [ ] Tests in happy-dom that fail without the change — one per key, following src/drag.test.ts's setup: the request each key makes (method, URL, body) and the focus that results.

Files I expect to change

static/board.<new-hash>.js (rename by content, delete the old file, update BOARD_JS in src/pages/board.ts), src/pages/board.ts (shortcut list), a new src/keyboard.test.ts or an extension of src/drag.test.ts, README.md.

Risks

• Same keydown handler #69 is reworking: land after it or the two rewrites collide.
• Delete on a card with no confirmation is a real loss on a shared board. Undo covers it — but check that the toast says so, and if #50's "asks once" pattern has landed, reuse it rather than inventing a second dialog.
• Focus after a key that rerenders a card must not fall to <body>; the live path already restores focus by card id (line 483) — reuse it.

Suggested: scout, reviewed by juniper. Waits for #69.