[Linux] @ / shifted symbols from mobile soft keyboards clear the text field (UTF-8 input via Ctrl+Shift+U)

Nobody has claimed this yet.

### Describe the bug

On a Linux host, typing certain characters from a mobile Moonlight client's on-screen keyboard (e.g. Android Gboard) clears/corrupts the target text field instead of inserting the character. The most reliable trigger is `@`. This makes things like logging into a website over a Moonlight desktop stream very difficult.

### Steps to reproduce

1. Host: Linux, KDE Plasma 6 (Wayland), US keyboard layout, Sunshine `v2026.516.143833`.
2. Client: Moonlight Android, using Gboard.
3. Stream the desktop and focus a text field (e.g. Chrome's address bar).
4. Type `test@`.

### Expected behavior

`test@` appears in the field.

### Actual behavior

The `@` clears/corrupts the field. Letters that arrive as keycodes type fine; only the symbol does this.

### Root cause (from debug logs)

With `min_log_level = 1`, typing `@` logs:

```
--begin unicode packet--
text [@]
--end unicode packet--
Unicode, typing U+40
```

Gboard commits `@` as UTF-8 text, so it arrives as a `UTF8_TEXT` packet rather than a keycode. On Linux, `platf::keyboard::unicode()` (`src/platform/linux/input/inputtino_keyboard.cpp`) types UTF-8 via the IBus/GTK `Ctrl+Shift+U` + hex-codepoint method. That method is only honored by IBus-enabled apps; in Chrome / KDE / Wayland-native apps / password fields the leading `Ctrl` chord is interpreted as a shortcut (e.g. `Ctrl+U`) and clears the field.

For contrast, the same `@` when it arrives as a keycode works correctly:

```
keyCode [8032] (VK_2) modifiers [01] (Shift)
```

So the keycode+Shift path is fine; only the UTF-8 text path is broken.

### Environment

- Host OS: Nobara Linux 43 (KDE Plasma 6.6.4, Wayland)
- Host keyboard layout: `us`
- Sunshine: `v2026.516.143833`
- Client: Moonlight Android + Gboard

### Possible fix

Inject printable ASCII as real keystrokes (on a US layout `@` -> `Shift+2`) and keep the `Ctrl+Shift+U` method only for genuine non-ASCII. A fully layout-independent fix would resolve each codepoint against the active keymap via libxkbcommon. (A draft patch and reviewer discussion of the US-layout caveat are in #5273.)

Start in src/platform/linux/input/inputtino_keyboard.cpp and trace platf::keyboard::unicode() for UTF8_TEXT packets, comparing it with the working keycode path. Read the draft patch and reviewer discussion in #5273 before choosing the scope. Done means printable symbols no longer clear or corrupt Linux text fields while genuine non-ASCII input continues to work.

Written by the indexing model from the issue text.