client: recognize kitty keyboard protocol encoding of detach key

[mgabor3141]

Problem

The detach key (default Ctrl-\) does not work when the kitty keyboard protocol is active. This affects an increasing number of terminal + application combinations:

Terminals: kitty, wezterm, foot, ghostty, rio
Applications that enable it: fish shell, neovim, helix, kakoune

When the protocol is active, Ctrl-\ is sent as a CSI u sequence (ESC [ 92 ; <mod> u) instead of the raw byte 0x1C. Since client_mainloop() only checks pkt.u.msg[0] == KEY_DETACH (a single-byte comparison), the detach key is silently ignored.

Reproducing

# In kitty (or any terminal supporting the kitty keyboard protocol):
abduco -c test fish   # or: abduco -c test nvim
# Press Ctrl-\ — nothing happens
# But if you run `cat` first, then press Ctrl-\ — it detaches,
# because cat does not enable the keyboard protocol

Subtle gotcha: numlock

The modifier field in the kitty protocol encodes all active modifiers including lock keys: modifier = 1 + (shift:1 | alt:2 | ctrl:4 | super:8 | ... | capslock:64 | numlock:128).

So Ctrl-\ with numlock on is ESC[92;133u (not ESC[92;5u). A simple string match against a fixed sequence won't work — the modifier must be parsed as a bitmask.

Solution

Adds a small CSI u parser (is_csi_detach()) alongside the existing single-byte check. It:

• Extracts the Unicode codepoint and verifies it matches the configured detach key
• Parses the modifier value as a bitmask and checks that ctrl (bit 2) is set
• Ignores other modifier bits (numlock, capslock, shift, etc.)
• Handles the optional event type suffix (:1 press, :2 repeat, :3 release)
• Works with any detach key configured via -e

The change is backward-compatible — the legacy single-byte check remains, so terminals not using the protocol are unaffected.

Closes #66

[mgabor3141]

Note on read boundaries: A reviewer pointed out that both this patch and the existing single-byte detach check assume the key event arrives as a complete, self-contained read(). In theory, a CSI sequence could be split across two reads (e.g., over a congested SSH link), or coalesced with subsequent input into a single read.

This is a pre-existing architectural limitation — the original pkt.u.msg[0] == KEY_DETACH has the same assumption and has worked in practice for 10+ years. This patch intentionally keeps the same approach for consistency rather than introducing a buffering/state machine just for the CSI path.

If there's interest in making the input handling more robust across the board, both the legacy and CSI detach checks could benefit from a small ring buffer that scans across read boundaries. Happy to do that work in a follow-up if desired.