## What happened

On a multi-layout keyboard setup where a secondary layout doesn't produce Latin letters at the physical C/V/X key positions (e.g. Cyrillic/Russian, but this would affect any non-Latin layout the same way), the default Universal copy/paste/cut shortcuts (`SUPER+C`, `SUPER+V`, `SUPER+X`) silently do nothing while that layout is active. A Hyprland OSD toast appears:

```
Runtime error in lua:
=[C]:-1: send_key_state: key not found
```

## Root cause

`default/hypr/bindings/clipboard.lua` triggers the shortcuts correctly regardless of active layout (Hyprland's bind matching is layout-agnostic by design via `input:resolve_binds_by_sym = false`). But the *injected* keystroke is sent by keysym **name**:

```lua
o.bind("SUPER + C", "Universal copy", universal_clipboard_shortcut("CTRL", "C", "CTRL", "Insert"))
o.bind("SUPER + V", "Universal paste", universal_clipboard_shortcut("CTRL", "V", "SHIFT", "Insert"))
o.bind("SUPER + X", "Universal cut", send_shortcut_once("CTRL", "X"))
```

`hl.dsp.send_key_state` resolves that name (`"C"`, `"V"`, `"X"`) against the **currently active** keyboard layout/group, not a fixed reference layout. If the active layout has no key that produces that Latin letter (true for Cyrillic and other non-Latin layouts), the lookup throws `key not found` and the injected Ctrl+C/Ctrl+V/Ctrl+X never happens — so the shortcut appears to just fail with no clipboard action.

This is the same class of bug the default config already works around elsewhere for a *trigger* key (see the `code:` comment pattern), but here it's the *injected* key inside `send_key_state` that isn't layout-pinned.

## Steps to reproduce

1. Add a second, non-Latin keyboard layout, e.g. in `~/.config/hypr/input.lua`:
   ```lua
   hl.config({ input = { kb_layout = "us,ru", kb_options = "grp:alt_shift_toggle" } })
   ```
2. Switch to the non-Latin layout.
3. Copy something to the clipboard (e.g. a screenshot).
4. Focus a normal (non-terminal) window and press `SUPER+V` (or `SUPER+C` / `SUPER+X`).

## Expected

Copy/paste/cut works the same regardless of which layout is currently active, matching the layout-agnostic behavior of the bind trigger itself.

## Actual

Hyprland shows a `send_key_state: key not found` runtime error toast (see attached screenshot) and no clipboard action occurs.

## Suggested fix

Send the injected key by physical position instead of by symbol name, e.g.:

```lua
o.bind("SUPER + C", "Universal copy", universal_clipboard_shortcut("CTRL", "code:54", "CTRL", "Insert"))
o.bind("SUPER + V", "Universal paste", universal_clipboard_shortcut("CTRL", "code:55", "SHIFT", "Insert"))
o.bind("SUPER + X", "Universal cut", send_shortcut_once("CTRL", "code:53"))
```

(`code:54`/`55`/`53` are the physical C/V/X key positions in Hyprland's xkb keycode numbering — layout-independent.) This mirrors the existing `code:49` workaround already used elsewhere in the default config for a layout-dependent trigger key, applied here to the injected key instead.

I've applied this fix locally as a user override and confirmed it resolves the issue.

## System details

- Omarchy version: 4.0.3-1
- Hyprland version: 0.56.2 (v0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f)
- `kb_layout`: `us,ru`, `kb_options`: `compose:caps,grp:alt_shift_toggle`