[Windows] Fix Korean 3-beolsik IME dropping space, digits and punctuation - #194270

Fixes #140537

Problem

With the Microsoft Korean IME set to a 3-beolsik layout (390 or Final), a space, digit or punctuation character typed into a TextField on Windows is silently dropped, both while Hangul is being composed and when nothing is being composed. 2-beolsik is unaffected.

Screen Recordings

Microsoft Korean IME, 3-beolsik 390, windows 10 22H2

Before - the space, digit and period are dropped.

After - all characters are inserted.

Cause

IMM32 does not guarantee the relative order of WM_IME_COMPOSITION with GCS_RESULTSTR and WM_IME_ENDCOMPOSITION: the WM_IME_COMPOSITION, WM_IME_ENDCOMPOSITION and WM_IME_STARTCOMPOSITION pages describe each message in isolation, and Microsoft's own sample inserts the result string when GCS_RESULTSTR is set without referring to WM_IME_ENDCOMPOSITION at all. Most IMEs send the result first, and FlutterWindow is written for that order: OnImeEndComposition commits the composing text and destroys the IME window, and DefWindowProc is suppressed for these messages so that the result is not inserted twice via WM_IME_CHAR/WM_CHAR.

In the 3-beolsik layouts the IME consumes every key (WM_KEYDOWN with VK_PROCESSKEY) and emits the characters itself. Captured with a Win32 message probe on Windows 10 22H2 (19045), Microsoft Korean IME, 3-beolsik 390:

// "겨" is being composed, user presses Space
WM_KEYDOWN            vk=VK_PROCESSKEY scan=0x39
WM_IME_ENDCOMPOSITION                     <- arrives first; the GCS_RESULTSTR is already queued
WM_IME_COMPOSITION    GCS_RESULTSTR="겨 "  <- arrives after the end

// nothing is being composed, user presses Space
WM_KEYDOWN            vk=VK_PROCESSKEY scan=0x39
WM_IME_ENDCOMPOSITION                     <- no WM_IME_STARTCOMPOSITION was ever sent
WM_IME_COMPOSITION    GCS_RESULTSTR=" "

After WM_IME_ENDCOMPOSITION the composing text had already been committed and TextInputManager::GetString refused to read the result (ime_active_ was false), so the result string was dropped. Native controls are unaffected because DefWindowProc converts the result to WM_IME_CHAR/WM_CHAR regardless of order; Flutter suppresses that path.

Fix

• FlutterWindow::OnImeEndComposition peeks the message queue (PM_NOREMOVE, the same approach KeyboardManager already uses to look for a following WM_CHAR) and, if a WM_IME_COMPOSITION with GCS_RESULTSTR is already queued, defers ending the composition until that result has been processed. IMEs that send the result first see no change: nothing is queued, so the composition ends immediately as before.
• FlutterWindow::OnImeComposition applies a result to the composition when one is in progress (unchanged); delivers it via OnText when there is no composition but the end was deferred (the bare-space case above); and ignores a result that arrives after a non-deferred end. The last case happens when the window loses focus during composition: the Korean IME sends WM_IME_ENDCOMPOSITION with nothing queued and then re-sends the committed text as a result, which previously was dropped only as a side effect of the ime_active_ check.
• TextInputManager::GetResultString no longer requires an active IME window. GetComposingString keeps the previous check, so composing-string handling is unchanged.

Tests

• MockWindow.OnImeEndCompositionWaitsForQueuedResult: the end is deferred until the queued result, and the result is applied to the composition before OnComposeEnd.
• MockWindow.OnImeCompositionResultWithoutCompositionIsText: end + result with no composition is delivered via OnText.
• MockWindow.OnImeCompositionResultAfterEndCompositionIsIgnored: the focus-loss re-send is not inserted again.
• OnImeCompositionResult and OnImeCompositionResultAndCompose now start a composition first, matching the real message order. MockWindow gained a Win32PeekMessage mock.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.