Add GTK_IM_MODULE to fcitx environment defaults

[tonyfarson]

What

default/environment.d/10-omarchy-fcitx.conf sets INPUT_METHOD,
QT_IM_MODULE, XMODIFIERS, and SDL_IM_MODULE for fcitx5, but not
GTK_IM_MODULE. This adds it.

Why

Without GTK_IM_MODULE, GTK-based and Chromium/Electron apps fall back
to the legacy XIM input protocol instead of fcitx5's module. XIM has a
long-documented history of dropped/eaten keystrokes under fcitx
(fcitx/fcitx5#1000 and others), and since the manual notes fcitx5 runs
"as part of every session" on Omarchy — not just for users who've added
a CJK input engine — this affects any GTK/Electron app on a stock
install, whether or not the user ever touches input methods.

I ran into this as consistently dropped characters in an Electron app
(Dabble, a writing app) — worse specifically when its live spellcheck
was on, which makes sense: spellcheck triggers far more IME
composition-state queries than plain typing, and that extra traffic is
exactly what the XIM fallback path handles poorly.

Verification

• Confirmed GTK_IM_MODULE was unset in a live session while the other
  three variables were present, tracing back to this file.
• Added GTK_IM_MODULE=fcitx via a user-level environment.d override,
  logged out and back in, and the dropped-keystroke behavior in the
  affected app went away with spellcheck re-enabled.
• ./test/all passes (test/cli, test/shell both green after fixing
  an unrelated local mise node-version gap in my dev environment).

Happy to add anything else that would help evaluate this for a future
dot release.

[tonyfarson]

Closing this — a re-test found the premise doesn't hold up, and I'd rather withdraw it than have reviewers spend time on something I can no longer stand behind.

What I got wrong: I diagnosed Dabble's dropped keystrokes as XIM fallback from a missing GTK_IM_MODULE, fixed it, verified it, and opened this PR. Retesting today (triggered by fcitx5's own "Wayland Diagnose" notification recommending the opposite — unset GTK_IM_MODULE when a Wayland input-method frontend is already active) found the fix doesn't actually reproduce anymore, and closer inspection shows it couldn't have been the mechanism in the first place:

$ fcitx5-diagnose
...
Group [wayland:] has N InputContext(s)
  IC [...] program:dabble frontend:wayland_v2 cap:... focus:0

Dabble (Electron, native Wayland/Ozone) connects to fcitx5 through the Wayland text-input protocol directly — it never goes through GTK's immodule system, so GTK_IM_MODULE has no effect on it regardless of value. GTK_IM_MODULE=fcitx is correctly configured on this machine (verified: GTK3/GTK4 immodule files present and loading, per fcitx5-diagnose's own Gtk section) — it just isn't in the code path this app uses. The original "it's fixed" result was very likely a false positive from something else clearing at the same time (a logout/login re-establishing fcitx5's connection state, most likely).

Where the actual bug lives: Chromium/Electron's text-input-v1 implementation — the only Wayland IME protocol version Electron supports. Per fcitx5's own wiki (https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland), Chromium's own developers describe this protocol support as "not very stable" and "only supposed to be used internally, not well supported." Forcing the app onto XWayland instead (where it uses fcitx5's mature dbus frontend via GTK's immodule) reliably fixes it:

Group [x11::0] has 1 InputContext(s)
  IC [...] program:dabble frontend:dbus cap:... focus:0

That's an app-level (Dabble should offer/default to XWayland, or Electron should fix text-input-v1) issue, not an Omarchy defaults issue. Sorry for the noise — happy to open something else if I find a genuinely Omarchy-scoped issue in here, but this isn't it.