Fix WezTerm compatibility: handle both terminal response orders

[OrbitalHustler]

Different terminal emulators send the kitty keyboard protocol query responses in different orders:

• Standard terminals: ESC[?u ESC[?c
• WezTerm: ESC[?c ESC[?u

Previously, kkp read events until seeing 'c', which caused WezTerm's response (where 'c' comes first) to be truncated. The pattern matching then failed because it only expected the standard order.

This patch:

1. Reads all events until timeout instead of stopping at 'c'
2. Updates regex patterns to match both response orders
3. Removes line-start/eol anchors for more flexible matching

The validation logic remains unchanged - we only verify the terminal supports KKP, then send our desired enhancement flags regardless of what the terminal reported.

Tested with WezTerm on WSL2 Debian and maintains compatibility with standard terminal implementations.

[benotn]

Hi, thanks for the PR and the work you spent investigating/implementing this. In principal I am fine with merging this, I just wonder why Wezterm does it this way?

the protocol says: "If an answer for the device attributes is received without getting back an answer for the progressive enhancement the terminal does not support this protocol." I guess it is not completely specific that the progressive attributes should come first but I somehow read it like that. Do you know if there is a reason why wezterm first sends the device attributes and then the enhancement flags when the query first asks for the progressive enhancements flags and then the device attributes?

As said, we can fix it here, and thanks again for the patch, but maybe fixing it in wezterm should also be an option.