fix(win32): drop modifiers from IME-committed text to avoid CSI-u garbling

[nanasess]

Problem

With a Japanese IME (reproduced with CorvusSKK), text committed from a conversion arrives in the WSL shell as escape-sequence garbage instead of the actual characters:

typed	expected	actual
相	相	ESC[30456;5u
今日	今日	ESC[20170;5uESC[26085;5u

Direct kana input (no conversion) and pasting are unaffected.

Cause

SKK-style IMEs confirm a conversion with Ctrl+J, so Ctrl is still physically down at the moment the committed characters are delivered via WM_CHAR.

handleTextInput (src/apprt/win32/App.zig) reads the live modifier state with getModifiers() and puts it on KeyEvent.mods unchanged. The core's legacy encoder (src/input/key_encode.zig) encodes any Ctrl + single codepoint as a fixterms CSI <codepoint>;<mods>u sequence — ;5u being Ctrl — so the committed codepoint is emitted as CSI-u instead of raw UTF-8.

This is consistent with the observed behaviour: confirming with Enter (Ctrl not held) never reproduces the problem.

Fix

Non-ASCII output from WM_CHAR/WM_SYSCHAR can only come from one of two places:

1. Composition — an IME commit (Ctrl held) or a dead key / AltGr (Ctrl+RightAlt). The modifiers were consumed to produce the character, not to trigger a shortcut.
2. An intentional Alt + <non-ASCII key> shortcut, which should still be encoded as meta / ESC-prefixed.

So for codepoint >= 0x80:

• Alt held without Ctrl → keep the modifiers (case 2 preserved).
• every other case, i.e. Ctrl held (SKK commit, AltGr) → clear the modifiers so the core emits the raw UTF-8 text.

Control characters (< 0x20) are already filtered out earlier in the function, and the existing AltGr consumed_mods handling right above is left intact for the ASCII path.

Testing

Built for Windows and run against WSL:

• CorvusSKK conversion + Ctrl+J commit → correct characters in zsh, no CSI-u.
• Enter commit, direct kana input, paste → unchanged.
• Alt + <non-ASCII> and ordinary Ctrl shortcuts (Ctrl+C, Ctrl+D, ...) → unchanged.

This has been running as a patch in my fork (nanasess#8) in daily use for a couple of weeks without regressions before opening this PR.

Notes / scope

This is a deliberately minimal fix on the WM_CHAR path. A more thorough approach would handle WM_IME_CHAR / WM_IME_COMPOSITION explicitly (including preedit rendering), which is a much larger change — happy to go that route instead if you'd prefer.

AI disclosure

Per AI_POLICY.md: this change was developed with Claude Code assisting in the investigation, and the code comment and this PR description were drafted with its help and edited by me. I diagnosed and verified the behaviour on real hardware, and I understand and stand behind the change.