Text input Select All / Copy / Cut / Paste shortcuts don't work with non-Latin keyboard layouts

[Farori]

Bevy version and features

0.19.0, default features (also affects current main).

[Optional] Relevant system information

Windows 10 / Linux — reproducible on any OS. Not rendering-related.
Reproducible with any non-Latin keyboard layout (Arabic, Ukrainian, Russian, Greek,
Hebrew, etc.).

What you did

1. Run the text_input example (or any app using the TextInput /
   EditableText widget from bevy_ui_widgets).
2. Switch the OS keyboard layout to a non-Latin one (e.g. Ukrainian).
3. Type some text, then press Ctrl+A (Cmd+A on macOS), Ctrl+C,
   Ctrl+X, Ctrl+V.

What went wrong

• Expected: standard editing shortcuts (Select All / Copy / Cut / Paste)
  work regardless of the active keyboard layout, as they do in native
  text fields and browsers.
• Actual: none of these shortcuts work while a non-Latin layout is active.
  Switching back to a US/Latin layout makes them work again.

Additional information

The cause is in bevy_ui_widgets/src/text_input.rs,
on_focused_keyboard_input: the shortcuts are matched against the
logical key:

(COMMAND, Key::Character(c)) if c.eq_ignore_ascii_case("a") => {
    queue_edit(TextEdit::SelectAll);
}

With a Russian layout, Ctrl+A arrives as Key::Character("ф"),
Ctrl+C as "с" (Cyrillic), etc., so the guards never match. The
layout-independent Named keys (arrows, Home/End, Backspace, Shift+Delete)
work fine.

The winit docs for KeyEvent::logical_key explicitly warn against using
it for keyboard shortcuts for exactly this reason:
https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html

Possible fixes:

1. Match these four shortcuts on the physical key_code
   (KeyCode::KeyA/KeyC/KeyX/KeyV) when a COMMAND modifier is held.
   Caveat: on Latin non-QWERTY layouts (e.g. AZERTY) the physical position
   differs from the key label, so pure physical matching relocates the
   shortcuts there.
2. Hybrid approach (what most toolkits/browsers do): match logical_key
   first, and fall back to the physical key_code when the logical key is
   not an ASCII character. This keeps AZERTY/QWERTZ conventions intact and
   fixes non-Latin layouts.
3. Longer term: expose winit's key_without_modifiers /
   layout-aware key data in bevy_input.

[alice-i-cecile]

Excellent bug report. Thanks for digging into the root cause. Let's go with the hybrid approach here <3

Can you please spin up a separate issue for the key_without_modifiers work?