fix(attach): reclaim leader on kitty keyboard input

[wegel]

Follow-up to #141.

#141 fixed the case where the daemon kept a stale leader fd after a client disconnected, but it explicitly left one remaining gap: non-leader input could still be ignored when libghostty rejected valid Kitty CSI u key sequences with colon subparameters.

This patch handles that case directly in isUserInput().

Problem

When a non-leader client sends keyboard input like:

• \x1b[102;1:1u
• \x1b[57444;1:1u

libghostty warns and does not classify the sequence as user input. As a result, handleInput() treats the payload as non-user input and refuses to transfer leadership to the active client.

In practice, that leaves a re-attached client unable to take control even though its input is reaching the daemon.

Fix

Recognize Kitty CSI u key sequences directly before falling back to the libghostty parser:

• parse CSI key-code[:alternates] ; modifiers[:event-type] [; text-codepoints] u
• accept press and repeat events
• reject release events
• preserve the existing mouse/focus exclusions

This keeps the change scoped to leader detection only. It does not change detach handling or terminal state restoration.

Test plan

• zig build test
• zig build -Doptimize=ReleaseSafe --prefix ~/.local
• manually reproduced with a session attached from two clients:
  • first client creates and owns the session
  • second client sends Kitty CSI u keyboard input
  • second client now correctly becomes leader instead of being ignored