[Feature] Fully user-configurable keybindings for all actions via one keybindings file

[stanleytejakusuma]

Summary

Make all keybindings user-configurable through a single surface, instead of a mix of hardcoded app bindings, per-action config keys, and extension-registered shortcuts that may or may not wire depending on session type.

Problem

Right now keybinding configuration is uneven:

• App-level bindings live in code, with a partial override surface via keybindings.json (see [Feature] More configurable keybinding behavior for enter/return and `submit` vs `newLine` #1411 for tui.input.newLine, tui.input.submit, and a locally added tui.input.lineSubmit).
• Extension shortcuts registered with registerShortcut work in local sessions but silently disappear in daemon-backed chats (see the bug report on shift+tab effort-cycle, filed alongside this).
• There is no way for a user to rebind an arbitrary action to a key of their choice without editing extension code.

Proposed direction

A generic action to keys map, ideally one file:

1. Every action that can fire from a key gets a stable action id: built-in app actions and extension-registered shortcuts alike.
2. keybindings.json overrides by action id, e.g. { "actions.cycleThinkingLevel": ["shift+tab", "ctrl+alt+e"] }.
3. Extension shortcuts surface under the same mechanism, so they are discoverable in /hotkeys and rebindable without editing the extension.
4. Conflicts resolve deterministically, with the same precedence rule the keybindings manager already uses, and a warning when a user binding shadows an extension default.

This is modular rather than a pile of per-action toggles: one file, one precedence rule, one discovery surface.

Alternatives considered

• Keep hardcoding and add more toggles per action. Rejected: the config surface grows with every new action and never covers extensions.
• Only fix the daemon extension-shortcut gap (Support client-local UI extensions in daemon-backed interactive chats #1462). Rejected as a standalone: it fixes wiring but still leaves rebinding to code edits.

Related

• The shift+tab effort-cycle bug report (daemon-backed chats never bind extension shortcuts)
• [Feature] More configurable keybinding behavior for enter/return and `submit` vs `newLine` #1411: enter/return keybinding configurability, which proves the keybindings.json mechanism exists and users already want it extended
• Support client-local UI extensions in daemon-backed interactive chats #1462: client-local UI extensions in daemon-backed interactive chats