## Summary
On a stock Omarchy 4.0.4 install, fcitx5 has no way to display its candidate-word panel through the compositor. The moment any native Wayland window is maximized or fullscreened, IME candidates disappear entirely — for every app, with every IME engine (not WeTypeX-specific).

## Environment
- Omarchy 4.0.4-1 (Arch + Hyprland + omarchy-shell/Quickshell)
- Hyprland 0.56.2 (commit efb509937)
- fcitx5 5.1.22-1
- `WAYLAND_DISPLAY=wayland-1`, `XDG_SESSION_TYPE=wayland`
- IMEs tested: fcitx5-wetypex 2.2.3.657, fcitx5-mozc — both reproduce

## Root cause
fcitx5 in a Wayland session does not render its own candidate panel. Only two rendering paths exist:

1. **In-client via `zwp_text_input_v3`** — each app (Qt6 / GTK / Chromium) draws the candidate UI inside its own surface. This breaks when the window changes state (maximize / fullscreen) because Hyprland tears down and rebuilds the input focus group, and the app-side IME implementation races with fcitx5's wayland_v2 frontend re-sending cursor_rect.

2. **External kimpanel DBus client** — KDE Plasma, niri-shell, AGS, and Quickshell all implement this. **omarchy-shell does not.** Verified:
   ```
   $ find /usr/share/omarchy -name '*kimpanel*'
   (empty)
   $ gdbus call --session --dest org.freedesktop.DBus \
       --object-path /org/freedesktop/DBus \
       --method org.freedesktop.DBus.ListNames | grep -i kimpanel
   (empty)
   ```

`hyprctl layers` confirms no fcitx5 / kimpanel / wetypex namespace is ever registered:
```
Monitor eDP-1:
  Layer 0 (background): namespace=omarchy-background
  Layer 2 (top):        namespace=omarchy-bar
  Layer 3 (overlay):    (empty)
```

`fcitx5-diagnose` shows the 3 UI frontends enabled — none of them render on Wayland:
```
Found 3 enabled user interface addons:
    Classic User Interface         (X11 override-redirect — Hyprland doesn't render these)
    KDE Input Method Panel         (no external kimpanel consumer exists)
    DBus Virtual Keyboard          (on-screen keyboard, not candidate UI)
```

`fcitx5-diagnose` shows every focused client uses `frontend: wayland_v2`, confirming the in-client rendering path is the only thing in use:
```
IC [...] program:CI Buddy frontend:wayland_v2 ... focus:1
IC [...] program:foot     frontend:wayland_v2 ... focus:0
IC [...] program:chromium frontend:wayland_v2 ... focus:0
```

## Reproduction
1. Fresh Omarchy 4.0.4 install
2. `omarchy pkg add fcitx5-mozc` (or use any IME)
3. Open any native Wayland app (CI Buddy, foot, Chromium)
4. Trigger `Super+F` (maximize) on the focused window
5. Begin typing Chinese — candidate panel does not appear, characters do not commit

**Expected:** candidate panel floats above the maximized window, anchored to cursor rect.
**Actual:** candidate panel missing entirely.

## Proposed fix
omarchy-shell (Quickshell) should ship a kimpanel DBus listener that:
1. Subscribes to `org.kde.kimpanel.inputmethod` signal on session DBus
2. Renders the candidate list to a `wlr-layer-shell` surface at `top` level
3. Auto-positions to the cursor rect provided by fcitx5

Quickshell already exposes [Kimpanel types](https://quickshell.org/docs/types/Kimpanel/) — this is a ~50 LOC plugin, not a from-scratch implementation.

## Severity
Workaround: do not maximize. But this breaks the entire Hyprland "give this window my full attention" use case and effectively bans Chinese / Japanese / Korean input on Omarchy for any maximized window. It also makes Omarchy unusable for anyone whose main workflow is Chinese-language content creation.

## Related
- Cross-ref: fcitx5 issue about wayland_v2 cursor_rect not updating on window state change (filing simultaneously)
- KDE Bug 506095 (similar X11↔Wayland IME breakage pattern)
- fcitx5#1662 "candidate popup flashes once then never reappears" (same family)