Don't arm the _keyDownSeen gate on modifier-only keydowns

[52mzd]

Problem

On macOS, typing an IME's shifted punctuation with a direct commit — e.g. Shift+/ for the full-width ？ with Chinese Pinyin — silently drops the first press; the user has to type the key twice. Reproduced in Safari and in WKWebView (Tauri), reported as the held-modifier variant in #5887 (Zhuyin, Tauri 2 + WKWebView), #6144 (Pinyin, order beforeinput → input → keydown) and #5374 (JP layout, Shift+3 / Shift+2).

Real-device trace captured on macOS 26 (WKWebView, Tauri, Apple Pinyin), from capture-phase listeners on the helper textarea — _keyDownSeen read before xterm's own handling:

keydown   key=Shift  kc=16     ← arms _keyDownSeen = true
beforeinput data="："          ← IME commits before the character keydown
input     data="："  seen=1    ← dropped by (!ev.composed || !this._keyDownSeen)
keydown   key=：    kc=229     ← composition diff fallback sees the commit already
                                applied to the textarea → empty diff, not recovered
keyup     key=：    kc=186     ← resets _keyDownSeen
input     data="："  seen=0    ← second press now passes the gate

So only the first press is lost: the held modifier's keydown arms the gate, the character's keyup disarms it.

Fix

_keyDownSeen's only consumer is the _inputEvent dedupe guard. A modifier-only keydown never produces text, so arming the gate for it can only produce false positives — an insertText arriving while a modifier is held can only be an IME direct commit that no keydown delivered yet. The fix reuses wasModifierKeyOnlyEvent, the same helper _keyUp already uses:

this._keyDownSeen = !wasModifierKeyOnlyEvent(event);

The regular path is unchanged: a character keydown still arms the gate so its own insertText stays deduped (covered by a test).

Scope / not claimed to fix

• The rapid-typing rollover variant (second character dropped, Second character lost when IME reports keyCode=229 for all keys (e.g. Doubao IME on macOS English mode) #5887 OP; Deferred textarea diff in _handleAnyTextareaChanges duplicates or drops characters on key rollover when IME reports keyCode=229 (companion defect to #5887) #6045 analyzes how the gate and the deferred textarea diff interact) needs a coordinated change to both the gate and _handleAnyTextareaChanges; Deferred textarea diff in _handleAnyTextareaChanges duplicates or drops characters on key rollover when IME reports keyCode=229 (companion defect to #5887) #6045 warns that touching the gate alone converts drops into duplications there. This PR deliberately does not touch that.
• wasModifierKeyOnlyEvent does not include CapsLock (keyCode 20), so the CapsLock variant mentioned on Cannot type Shifted characters (e.g. #, ") or overlapping keys in Safari on macOS #5374 is not covered; extending the helper would also change _keyUp's focus semantics, so I left that to maintainer judgment.

🤖 Generated with Claude Code