Keep onKittyQueryResponse stable across rerender() calls

[costajohnt]

Ink.render() passed onKittyQueryResponse to App as an inline arrow function, so it was a new function on every call, including every public rerender(). In App, that prop is a dependency of handleReadable, which feeds attachReadableListener and handleSetRawMode, so every rerender() changed the setRawMode identity in StdinContext. Every mounted useInput, usePaste and useFocus then re-ran its raw-mode effect (setRawMode(false) then setRawMode(true)), and the count-hits-zero path called clearInputState(): the input parser was reset, the pending-escape flush timer cancelled and the readable listener detached and re-attached.

Anything buffered in the parser at that moment was lost:

• a pending Escape keypress never arrived;
• a split escape sequence (ESC[ then A) arrived as the plain key A with shift: true instead of upArrow;
• a bracketed paste spanning two stdin reads arrived in useInput as part2 and [201~, even with usePaste mounted.

In-tree setState re-renders do not trigger it, only rerender() does, and it happens whether or not kittyKeyboard is configured.

Make the callback a stable class property. Side effect: useStdin consumers no longer re-render on every rerender(), since the context value is stable again.

Tests (test/rerender-input.tsx): a pending Escape survives rerender(), an escape sequence split across two reads survives rerender(), a paste split across two reads survives rerender(), and rerender() does not remove the readable listener. All four fail on master.

Fixes #1009

[sindresorhus]

The implementation looks right to me. The callback belongs to the long-lived Ink instance and reads the current detection resolver when called, so making it a stable instance property is the smallest fix. Handling an unstable parent callback inside App would need extra ref or effect plumbing and introduce stale-callback timing concerns. useEffectEvent is not a better fit here because it is intentionally unstable and restricted to Effect-owned calls.

The new tests need one adjustment, though. Readable.push() plus a 2 ms sleep does not guarantee that the first chunk reached the parser before rerender(), so the buggy implementation can sometimes pass without exercising the bug. The sleep after rerender() can also cross the parser's 20 ms escape timeout under load, making the fixed implementation fail. I reproduced the latter locally.

Please use the existing synchronous stdin helper to deliver the chunks. Fake timers are only needed for the pending Escape timeout. For the split sequence, emit A immediately after the synchronous rerender(), and the paste test can also stay fully synchronous. That should make the tests deterministc.