fix(tao): forward Linux IME preedit into Compose

[takke]

Closes #558.

Linux was the last backend without input-method support, and it was not a
matter of degree: gtk::IMContextSimple is GTK's built-in fallback for Compose
sequences and Ctrl+Shift+U, and it never talks to the system input method. So
CJK input was impossible, not merely awkward. Typing aiueo and confirming
left a single stray a behind — five keystrokes swallowed, one leaked.

This is the other half of #558, after #603 did Windows.

What was wrong

platform_impl/linux/event_loop.rs carried the upstream // TODO Add actual IME from system and four consequences of it:

1. IMContextSimple was pinned, so ibus / fcitx5 / Mozc and the Wayland
   text-input protocol were never reached.
2. connect_preedit_changed was never wired, so the composition was invisible.
3. filter_keypress ran after the key had already been handed to the app,
   and its result was discarded — the Linux twin of the VK_PROCESSKEY leak
   fixed for Windows.
4. set_ime_position was a //TODO stub, so the candidate window had no idea
   where the caret was.

What this does

IMMulticontext instead of IMContextSimple, which resolves the platform
module the same way GTK's own text widgets do — the GTK immodule on X11, the
text-input-v3 client on Wayland — and routes its signals into the
ImePreedit / ImeCommit events added for macOS in #595 and extended to
Windows in #558. commit splits on whether a composition is open, the same
distinction the Windows backend draws between GCS_RESULTSTR and a plain
WM_CHAR. The context now follows the window's focus instead of latching
focus_in once at construction.

Keys the input method consumed no longer reach Compose. filter_keypress
runs first and stops propagation, but that alone is not enough, and the reason
is worth spelling out: only the press is withheld. On Wayland the compositor
filters those keys out of the stream before the client sees them — text-input-v3
has no way to say "filtered" — while the matching release arrives regardless.
Compose fires clickable's onClick on KeyUp, so a release with no press behind
it activates whatever holds focus: the Return that merely confirmed a
conversion went on to press a button. Tracking which presses were actually
forwarded and dropping unmatched releases covers the X11 path too, where
filter_keypress withholds the press in-process for the same net effect.

Modifier state is derived from each event rather than accumulated. This one
is not IME-specific, and it is in its own commit. ModifiersChanged was only
emitted when the key itself was a modifier, which holds up only while every
release arrives — and on X11 they do not, because ibus re-injects what it
forwards. A dropped Control release left Compose reading every later plain
Return as Ctrl+Return for the rest of the session. GDK reports the live mask on
every event, so deriving the state from the event self-heals on the next
keystroke. The same traces also show a Meta_L press answered by an Alt_L
release, which pair-based bookkeeping cannot survive either.

The candidate window is kept off the caret. GTK is area-based where IMM32
is point-based: gtk_im_context_set_cursor_location receives the region the
cursor covers and the input method stays off it, so the point that
set_ime_position can carry is not enough — pass one and Mozc's "Tab to
select" hint sits on the composition it is describing. WindowExtUnix grows
set_ime_cursor_area, mirroring the winit API of that name;
set_ime_position becomes a zero-sized area at the point, so the
cross-platform call behaves as documented. Two further corrections were needed
to land it in the right place: GDK works in logical pixels (invisible at scale
1, wrong on HiDPI), and the caret arrives in client-area coordinates while GTK
wants them relative to the toplevel GdkWindow — which on a CSD window also
spans the invisible resize border and drop shadow. Measured here that offset is
(26, 23); without it the input method placed the caret a shadow's height too
high and drew its list straight over the text.

Tests

platform_impl::linux::ime::ImeState owns the decisions the signal handlers
used to make inline, so they can be replayed without a display. Ten cases, all
taken from real traces on GNOME 46 with ibus + Mozc — the withheld press with a
delivered release on both Wayland and X11, the confirming Return that activated
a control, the swallowed Control release, the asymmetric Meta_L/Alt_L
report, and a regression guard that Ctrl+C and friends still pass the gate.

cargo test --lib from src/main/native/vendor/tao. The Windows backend draws
the same line with its ImeSource trait; Linux needs no trait, because GTK
pushes everything and there is nothing to read back.

Verification

Real-device testing on GNOME 46 (Wayland session) with ibus + Mozc, on both
the Wayland path and the XWayland one (NUCLEUS_TAO_LINUX_RENDERER=x11) — the
two resolve different modules (im-wayland.so vs im-ibus.so) and consume
keys by different mechanisms, so both were exercised:

• inline preedit while composing
• the confirming Return inserts no newline and activates nothing
• BackSpace during composition stays inside it
• committed text is inserted exactly once
• the candidate window and the suggestion hint sit below the caret and follow
  it across lines
• no regression in ASCII input, or in Ctrl+C / Ctrl+V / Ctrl+Return

:decorated-window-tao:check passes (ktlint / detekt / test / apiCheck /
koverVerify).

One question for you

WindowExtUnix::set_ime_cursor_area adds public API. It is named after the
winit call with the same signature, and the area is genuinely required — GTK
cannot be told to avoid a region it was never given. If you would rather see
this shaped differently (widening set_ime_position, keeping it
pub(crate) and driving it from elsewhere, or another name), say so and I will
change it.

[kdroidFilter]

Amazing ! Thanks !