Arrow up/down always navigate prompt history (no edge-aware line nav); keybindings.json override ignored in Ghostty

Bug Description

In the chat input, the up/down arrow keys always jump to prompt history, even when the cursor is in the middle of multi-line text. Previously they did edge-aware navigation — moving the cursor between lines while editing, and only navigating prompt history when the cursor was at the first/last line (e.g. an empty input). That edge-aware line navigation appears to have regressed: arrows now go straight to history regardless of cursor position.

Additionally, attempting to override this via ~/.claude/keybindings.json has no effect. Unbinding the keys and remapping history to other keys:

{
  "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
  "bindings": [
    {
      "context": "Chat",
      "bindings": {
        "up": null,
        "down": null,
        "ctrl+p": "history:previous",
        "ctrl+n": "history:next"
      }
    }
  ]
}

...does not change the behavior after a full restart — up/down still navigate history. The JSON is valid (/doctor reports no issues). This suggests up/down keystrokes from this terminal may not be matching the binding table, so neither the null unbind nor the native edge-detection applies.

Expected Behavior

• While editing multi-line text, up/down move the cursor between lines.
• up/down navigate prompt history only when the cursor is at the top/bottom line (or the input is empty).
• Failing that, keybindings.json overrides for up/down in the Chat context should take effect.

Actual Behavior

• up/down always navigate prompt history, regardless of cursor position within the input.
• keybindings.json overrides for up/down (including null unbind) have no effect.

Environment

• Claude Code: 2.1.162
• Terminal: Ghostty
• OS: macOS 26.5 (build 25F71), Darwin 25.5.0
• Node: v23.7.0

Additional Notes

Ghostty supports the Kitty keyboard protocol, which encodes arrow keys differently from legacy escape sequences. A possible cause is that arrow-key CSI sequences under the enhanced keyboard protocol aren't being matched to the up/down keystroke identifiers in the binding/edit handler, so both the native edge-aware logic and user keybindings are bypassed.