tui: registering a cmd/super keybind swallows first press of lowercase "c" in prompt

Summary

Adding any cmd/super keybinding to cli.json causes the full TUI to silently
consume the first press of lowercase c in the prompt input (two taps required
to type one c). alt bindings are unaffected.

Environment

• opencode version: 0.0.0-beta-19296 (also reproduced on 0.0.0-beta-19242)
• OS: macOS (Darwin 24.6.0, arm64)
• Terminal: Ghostty 1.3.1 (also reproduced in cmux)
• Shell: /bin/zsh
• Install/channel: beta (npm)

Reproduction

1. Add to ~/.config/opencode/cli.json:

   { "keybinds": { "session.new": "cmd+n,cmd+t" } }
   

2. Restart opencode2 (or let it hot-reload)
3. In the prompt input, press c once → nothing appears
4. Press c again → a single c appears

Minimal trigger: any binding containing a cmd/super chord (e.g.
"session.new": "cmd+n" alone). Alt-only bindings (alt+n,alt+t) do NOT trigger it.

Expected Behavior

A single c press inserts the character immediately.

Actual Behavior

The first press of lowercase c is swallowed; two presses produce one c.
Uppercase C, other letters, and deleting c are unaffected. Removing the
cmd keybind (hot-reload) instantly restores normal behavior.

Additional Context

• opencode2 mini types c with one press — full TUI only.
• OpenCode V1 types c normally on the same machine/terminal.
• Reproduces with empty plugin list, no custom theme, and no other custom
  settings — only the cmd keybind is required.
• c = 0x63 is a VT/CSI final byte (CSI c = Send Device Attributes);
  likely the same opentui KeyHandler bug family as #28638 (n, 0x6E) and
  #28026 (p), which was fixed in V1.
• Related observation: after running opencode2, the kitty keyboard protocol
  appears to leak into the terminal — CapsLock+letter keys (e.g. c) render
  lowercase in the shell until the terminal is fully restarted. Possibly
  related to the same input/encoding layer.