input: rearm IME once after keyboard focus enter #2282

It fixes #2279

Problem

On KWin + fcitx5, after several workspace/focus switches, foot can enter a state where
zwp_text_input_v3 is focused/enabled but no longer receives commit_string events.
At that point input falls back to plain keyboard/XKB path only.

Why this change is protocol-aligned

The text-input-v3 protocol requires re-enabling when focused text input changes, and
defines enable as a state reset point:

• "This request must be issued every time the focused text input changes"
• "This request resets all state associated with previous enable/disable/... state"

So recovering by forcing a fresh disable+enable cycle is consistent with protocol intent
when the IME pipeline gets stuck after focus transitions.

What this patch does

• Add a one-shot rearm_pending flag per seat.
• Set it on keyboard_enter, clear it on keyboard_leave.
• On the first post-focus keyboard_modifiers event, if IME focus is active:
  • call ime_disable()
  • call ime_enable()
  • clear rearm_pending

This keeps the workaround bounded to one rearm per focus session.

Why this is better than previous behavior

Previously, if KWin/fcitx5 ended up in a non-committing v3 state, foot stayed stuck
until another external state reset happened.
Now foot proactively performs a single local rearm at a stable post-focus point.

Related implementation notes

QtWayland follows a similar enter/leave state model for text-input-v3
(enter -> enable+state update, leave -> disable+commit), and also prefers v2 over v3
on KWin for compatibility reasons.

Also, I wonder why KDE isn't sending an ime::enter after a keyboard_enter()? Unless I'm reading the IME documentation wrong, it should. And if it isn't, it's a KDE bug:

Focus moving throughout surfaces will result in the emission of zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused surface must commit zwp_text_input_v3.enable and zwp_text_input_v3.disable requests as the keyboard focus moves across editable and non-editable elements of the UI. Those two requests are not expected to be paired with each other, the compositor must be able to handle consecutive series of the same request.

Also, I wonder why KDE isn't sending an ime::enter after a keyboard_enter()? Unless I'm reading the IME documentation wrong, it should. And if it isn't, it's a KDE bug:

Yes, it's absolutely a KDE bug; it seems they lose zwp_text_input_v3.enter in a few cases, such as when switching between workspaces or after other effects (maybe it's an effects issue in general).

Why wait until keyboard_modifiers() to re-arm? Why not just do it in keyboard_enter()?

Because I saw some activities in keyboard_modifiers, but not for keyboard_enter. But I will check again. This patch is more like a workaround. I have been using it for the past few weeks, and it has been working perfectly.

In general, I don't merge workarounds for compositor bugs. I can keep this MR around for a while if you want, but don't expect it to be merged.

Yes, please keep it here for a while, in the meantime, I will try to fix it from the KWin side.