fix(tao): stop key roll-over from being read as a PressAndHold accent pick

[takke]

Typing quickly on macOS silently drops characters. In our app (ZonePane, Compose text fields) typing Xcode at normal speed reliably lands as Xcde — one character short, and the previous character is the one that disappears.

This is not IME-specific: it hits plain ASCII typing, so every macOS Nucleus user is affected.

What happens

g_letter_key_down is only cleared on the base key's keyUp (nucleus_key_up). Fast typists roll over — the previous key is still physically down when the next one goes down — so during ordinary typing that flag is YES for long stretches, with a different key already being processed.

Any selectedRange / attributedSubstringForProposedRange query landing in that window runs nucleus_note_press_and_hold_query(), which checks only g_did_insert_base && g_letter_key_down and arms g_press_and_hold_queried. The next insertText: then matches g_press_and_hold_queried && !sameAsBase && length > 0 and is routed into the replace-commit path — deleteSurroundingTextInCodePoints(1, 0) eats the character that was just committed, and the new one takes its place.

X  keyDown → insertText("X")   base="X"
c  keyDown → insertText("c")   base="c"
o  keyDown → insertText("o")   base="o", g_letter_key_down = YES
   ── Compose updates → IMKit queries selectedRange → picker "detected" ──
d  keyDown (o still down)      → hijacked: delete "o", commit "d"
e  keyDown → insertText("e")
                                → "Xcde"

The existing reset

if (!g_letter_key_down && isLetterDown && !isRepeat) { g_press_and_hold_queried = NO; }

cannot help: g_letter_key_down is precisely the flag that stays YES through a roll-over.

Fix

Two guards, both resting on the same invariant — PressAndHold only ever continues on the same physical key, and its accent is picked with a number key, the arrows or the mouse, never with a letter:

• nucleus_note_press_and_hold_query() ignores queries that arrive while a different key is being processed (event.keyCode != g_base_key_code), so ordinary typing no longer arms the picker.
• nucleus_insert_text() drops any pending picker state when a different letter key goes down, so even a stale flag cannot hijack a commit.

The genuine flow is untouched: the picker engages on the base key's repeats (isRepeat, same keyCode) and the accent arrives on a non-letter event.

Testing

• :decorated-window-tao:test / ktlintCheck / detekt / apiCheck all green.
• Manual on a real Mac (M4 Pro): Xcode and other fast-typed words now land intact; repeated letters (aaa, ee) are fine; Japanese IME input via ATOK and Kotoeri (Tao/macOS: IME marked text (preedit) never reaches Compose, and the commit Enter is delivered as a raw KeyDown — CJK input is unusable #595) still types cleanly — preedit, commit and arrow keys all behave.

Related: #595, #596, #599.