### What happened

Selecting an **image** entry in the Omarchy clipboard manager and pressing Enter puts the image on the clipboard correctly, but nothing is pasted when the focused window is a terminal. The same action works in GUI/webapp windows.

### What I expected

The selected image to be pasted into the focused application, the same way text entries are.

### Root cause

`bin/omarchy-clipboard-paste-file` always finishes with a `Shift+Insert` keystroke:

```bash
wl-copy --type "$mime" < "$path"

if [[ $copy_only == "true" ]]; then
  exit
fi

sleep 0.15
wtype -M shift -k Insert -m shift 2>/dev/null || true
```

The `wl-copy` half is correct — the image really is on the clipboard, and `wl-paste --list-types` reports `image/png` with byte-identical content.

The problem is the keystroke. Terminal emulators bind `Shift+Insert` to their own **text-only** paste and consume it before the running application ever sees it. foot's default, for example:

```ini
clipboard-paste=Shift+Insert Control+Shift+v XF86Paste
```

So the sequence is: image goes on the clipboard with only an `image/png` flavor, `Shift+Insert` is delivered, foot intercepts it, foot looks for a text flavor to write to the tty, finds none, and nothing happens. No error, no feedback.

By contrast, `Ctrl+V` is *not* in foot's binding list, so it passes through to the running program. Terminal applications that support image paste (Claude Code, for instance) read the clipboard themselves on `Ctrl+V` and pick the image up fine. That is why pressing `Ctrl+V` manually works while the clipboard manager's own paste does not.

This also explains why GUI apps are unaffected: there `Shift+Insert` reaches the toolkit's paste handler, which honours non-text clipboard flavours.

`bin/omarchy-clipboard-paste-text` uses the same `Shift+Insert` keystroke, which is correct for text (and deliberately terminal-safe, since `Ctrl+V` is not paste in a terminal). The image path appears to have inherited it without adjustment.

### Steps to reproduce

1. Copy any image (e.g. `omarchy capture screenshot`).
2. Focus a terminal running an application that accepts pasted images (Claude Code is an easy target).
3. Open the clipboard manager (`Super+Ctrl+V`), select the image entry, press Enter.
4. Nothing is pasted. The overlay closes and the terminal is unchanged.
5. Press `Ctrl+V` manually instead — the image pastes, confirming it was on the clipboard the whole time.

### Workaround

Use `Shift+Enter` in the clipboard manager (the `--copy-only` path), then press the application's own paste binding manually.

### Suggested fix

For image entries, send `Ctrl+V` rather than `Shift+Insert`, or skip the synthetic keystroke entirely when the focused window is a terminal and let the user paste. An image can never be pasted into a terminal's text-paste path, so `Shift+Insert` has no valid case here.

### Environment

- Omarchy 4.0.2-1
- Hyprland 0.56.2
- foot 1.27.0-2, wtype 0.4-2, wl-clipboard 1:2.3.0-1
- Reproduced with the stock `omarchy.clipboard` plugin, no local modifications

Still present on `master` as of filing — `bin/omarchy-clipboard-paste-file` is byte-identical to the installed copy.