[BUG] Super/Shift+F-key combos (e.g. hotkey remaps via keyd) leak as kitty keyboard protocol escape sequences into input

Description

When a system-level hotkey uses Super+Shift+high-numbered function key (e.g. Super+Shift+F23), Claude Code echoes the raw kitty keyboard protocol escape sequence — e.g. [57386;10u — as literal typed characters into the input field.

Other terminal applications (Ghostty, foot, etc.) receive the same key event but silently discard the unrecognized sequence. Claude Code does not, so it appears as garbage input.

Steps to Reproduce

1. Map a hotkey to Super+Shift+F23 via a key remapper (e.g. keyd on Linux: mouseforward = M-S-f23)
2. Open Claude Code in a terminal that supports kitty keyboard protocol
3. With Claude Code focused, press that hotkey
4. Observe [57386;10u (repeated for each key-repeat event while held) inserted into the input

Expected Behavior

Unrecognized kitty keyboard protocol sequences should be silently consumed, not echoed as literal characters.

Actual Behavior

[57386;10u (or similar CSI u sequences for modifier+Fkey combos) appears as typed text in the input field.

Environment

• OS: Fedora Linux 43, kernel 6.18.x
• Desktop: Hyprland (Wayland)
• Terminal: Ghostty (kitty keyboard protocol enabled)
• Key remapper: keyd (mouseforward = M-S-f23)
• Hotkey app: voxtype dictation daemon (grabs key via evdev, not Wayland — so the event reaches Wayland and is forwarded to the focused window)

Related Issues

• #16843 — same root cause, different key class (numpad keys in iTerm2)
• #28518 — same class (kitty protocol repeat events not handled)

The underlying issue is that Claude Code's kitty keyboard protocol parser does not handle the full CSI u codepoint range for modifier+function-key combos, allowing unrecognized sequences to pass through as literal input instead of being silently dropped.