feat: user configurable tui keybindings

[joshbarrington]

As referenced here: #1626 and the subsequent closed MR: #1629

First stage implementation for allowing user configurable keybindings.

@krissetto would like to get your thoughts and then we can discuss potential extensions/alternative implementations.

[aheritier]

/review

Any thoughts @krissetto ?

[aheritier]

Good foundation for configurable keybindings. The architecture (centralized KeyMap, defaults + override merge, caching) is sound and the refactoring of tui.go to use the shared KeyMap is a clear improvement.

Blocking items:

1. Type naming: Keybindings → Keybinding (singular for a single entry)
2. Undocumented behavioral change: The quit key now opens an exit confirmation dialog — this changes existing UX and should be explicitly noted/discussed
3. Missing docs: No user-facing documentation for how to configure keybindings

CI: Still running at review time — please confirm tests pass.

Also noting (non-blocking): PR title has a typo — "keybings" → "keybindings".

[docker-agent]

❌ PR Review Failed — The review agent encountered an error and could not complete the review. View logs.

[joshbarrington]

@aheritier this can be re-reviewed 👍

[aheritier]

/review

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

This PR introduces user-configurable TUI keybindings — a clean, well-structured implementation with good test coverage. Three issues were found in the new code:

1. Data race in ResetKeys() — writes keysOnce without a mutex while GetKeys() reads it concurrently (flagged by Go's race detector, and blocks safe hot-reload use).
2. Conflict detection not enforced in validateKeys — conflicting keys are logged but still bound to both actions, leading to ambiguous key dispatch.
3. Elicitation dialog exits without confirmation — the quit key in ElicitationDialog.handleKeyPress calls tea.Quit directly rather than stacking the exit confirmation dialog like every other quit path does.

A low-severity edge case was also noted: if a user maps quit to n/N, the exit confirmation dialog's Yes binding would capture it before the No binding.