## What happens

Text clipboard history silently stops recording. Image history keeps working, which makes it easy to miss — the clipboard manager still fills up, just with nothing you copied as text.

The cause is a `capture.sh` process that never exits:

```
$ ps -eo pid,ppid,etime,cmd | grep -E "wl-paste|capture\.sh"
   3495    2673  2-10:57:08 wl-paste --type text --watch .../clipboard/capture.sh text
   3497    2673  2-10:57:08 wl-paste --type image/png --watch .../clipboard/capture.sh image/png
 238185    3495  2-08:31:18 /bin/bash .../shell/plugins/clipboard/capture.sh text
```

`238185` had been running for over two days. Because `wl-paste --watch` waits for its command to exit before handling the next clipboard event, the text watcher is blocked for as long as that process lives — so every subsequent text copy is dropped. The image watcher is a separate process and is unaffected, hence text-only loss.

Killing the stuck `capture.sh` restores text capture immediately; no restart of the shell or the watchers is needed.

## Cause

`shell/plugins/clipboard/capture.sh` line 13 runs before the `case` dispatch, so it executes for **every** invocation including `text`:

```bash
types=$(wl-paste --list-types 2>/dev/null || true)
```

There is no timeout on it. `wl-paste` blocks indefinitely when the clipboard's owning client goes away mid-transfer, so a single bad copy wedges the script permanently.

The image path is already guarded against exactly this:

```bash
timeout 2s wl-paste --type "$mime" 2>/dev/null | emit_image "$mime"
```

but neither line 13 nor the final text read is:

```bash
wl-paste --type text --no-newline 2>/dev/null | emit_text
```

## Suggested fix

Wrap the unguarded `wl-paste` calls the same way the image branch already does:

```bash
types=$(timeout 2s wl-paste --list-types 2>/dev/null || true)
...
timeout 2s wl-paste --type text --no-newline 2>/dev/null | emit_text
```

A capture that has not completed in two seconds is not going to complete.

Optionally, `wl-paste --watch` could be invoked with a wrapper that bounds total runtime, so a hang in any future code path degrades to a dropped entry rather than a dead watcher.

## Steps to reproduce

Difficult to trigger deliberately, since it depends on a clipboard owner disappearing at the wrong moment. It has occurred twice here in ten days under normal desktop use. The failure is easy to confirm once present:

1. `ps -eo pid,etimes,comm,args | grep capture.sh` — a `bash` process running `capture.sh` with a large `etimes`
2. Copy text; nothing is added to `~/.local/state/omarchy/clipboard-history.json`
3. Copy an image; it *is* added
4. `kill -9` the stuck process — text capture resumes at once

## System

- Omarchy 4.0.1-1
- Framework 13 AMD (Phoenix1, gfx1101), Hyprland
- `shell/plugins/clipboard/capture.sh` identical to current `main` at time of writing