### System details

AMD Ryzen 5 PRO 4650U (Renoir iGPU), Omarchy 4.0.3-1, Quickshell 0.3.1-1, fcitx5 5.1.22-1, fcitx5-hangul 5.1.11-1, fcitx5-qt 5.1.15-1

### What's wrong?

Korean (Hangul) cannot be composed in the omarchy-menu search field, even though Fcitx5 works in every other application on the same machine. The menu only accepts raw single-character key events, so IME preedit/commit never reaches it.

This is not a missing-package or missing-environment problem. The Quickshell process has:

```
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
```

and `fcitx5-qt` is installed. Korean input works in Alacritty, Chromium, Nautilus, etc.

**Steps to reproduce**

1. Install `fcitx5`, `fcitx5-hangul`, `fcitx5-qt`; add Hangul to the Fcitx5 profile (or use #9299 once merged).
2. Open the omarchy-menu (Super+Space).
3. Switch Fcitx5 to Hangul and type e.g. `gks` (should compose `한`).

**Expected:** `한` appears in the search field and filters the list.
**Actual:** Switching Fcitx5 to Hangul has no effect inside the menu — the raw Latin letters `gks` are inserted as if the IME were off. The same toggle works immediately in any other window.

**Root cause**

`shell/plugins/menu/Menu.qml` does not use a Qt text-input control for the search field. The `keyCatcher` `Item` has `focus: true` and collects printable characters manually in `Keys.onPressed`:

https://github.com/omacom/omarchy/blob/quattro/shell/plugins/menu/Menu.qml#L1161-L1163

```qml
} else if (event.text && event.text.length === 1 && event.text.charCodeAt(0) >= 32 && event.text.charCodeAt(0) !== 127 && (event.modifiers === Qt.NoModifier || event.modifiers === Qt.ShiftModifier)) {
  root.setFilter(root.filterText + event.text)
  event.accepted = true
}
```

A plain `Item` does not participate in Qt's input-method protocol (`QInputMethodEvent`, `inputMethodComposing`, `inputMethodHints`). Fcitx5 delivers CJK text as preedit + commit events rather than as `QKeyEvent`s with `event.text`, so composition is silently dropped. The same applies to Japanese and Chinese IMEs.

This is the same code path already discussed in #7098 (crash traced through `Keys.onPressed → setFilter()`) and #8023 (numpad / AltGr characters filtered out by the same `event.text` + modifier checks). Together they show the hand-rolled key-event path is fragile for anything beyond direct Latin key input.

**Verified fix (local)**

I cloned the plugin (`omarchy plugin clone omarchy.menu`) and replaced the printable-character branch with a real `TextInput`:

- `TextInput { id: searchInput; focus: root.opened }` bound to `root.filterText`, filtering via `onTextEdited → root.setFilter(text)`.
- `Keys.onPressed` kept only for non-text commands (Escape, Enter, arrows, PageUp/Down, Delete, Backspace-on-empty → goBack) and bails early when `searchInput.inputMethodComposing` so preedit keys don't trigger shortcuts.
- `keyCatcher.forceActiveFocus()` → `searchInput.forceActiveFocus()`.

With that change Hangul composition works normally in the menu. I have not yet finished the integration (my first pass regressed the item list rendering), so I'm filing this as an issue rather than a PR for now; happy to follow up with a PR once it's clean, or if a maintainer prefers a different approach for keeping the menu keyboard-driven.

**Related:** #7098, #8023, #9299