## What happened

`omarchy plugin update` updated two plugins successfully, printed `omarchy-shell is not responding`, and exited 1:

```
$ omarchy plugin update --yes; echo "exit=$?"
bredda.localsend is up to date.
dev.git is up to date.
io.github.itsmoorgrove.protoncalendar is up to date.
jankeesvw.notification-center is up to date.
rocha.pasteimage is up to date.
shokupan.omenu is up to date.
Updated themo.mail-inbox.
Updated themo.monitor-profiles.
themo.nfl is up to date.
omarchy-shell is not responding
exit=1
```

Both checkouts were fast forwarded correctly and both plugins are loaded and enabled in the shell. `omarchy-shell shell ping` answers `ok` immediately afterwards. The shell never restarted, the quickshell PID was unchanged throughout. Nothing actually failed, but the command reports failure.

## Cause

`bin/omarchy-plugin-update` runs under `set -euo pipefail` (line 7) and ends with an unguarded IPC call:

```bash
if (( UPDATED_ANY )); then
  omarchy-shell shell rescanPlugins >/dev/null    # line 131
fi
exit $rc
```

`omarchy-shell` wraps every call in `timeout ${OMARCHY_SHELL_IPC_TIMEOUT:-2s}` and maps a timeout to exit 1. So when the rescan takes longer than 2 seconds, `set -e` aborts the script on line 131 and `exit $rc` (with `rc=0`) is never reached. The `>/dev/null` only silences stdout, so the error text still reaches the terminal.

Two seconds is not much headroom for this particular call. Measured on this machine with 9 git managed plugins:

| situation | duration | exit |
|---|---|---|
| rescan with nothing to reload | 0.05 s | 0 |
| rescan right after a real plugin update | 1.65 s | 0, just under the limit |
| second rescan while the first is still rebuilding | 2.01 s | 1, `is not responding` |
| same call with `OMARCHY_SHELL_IPC_TIMEOUT=10s` | 7.32 s | 0 |

The rescan itself always completes. Only the client gives up early.

## The same pattern is in three more scripts

All four call `omarchy-shell shell rescanPlugins >/dev/null` unguarded under `set -e`:

| script | line | what follows the rescan |
|---|---|---|
| `omarchy-plugin-update` | 131 | only `exit $rc` |
| `omarchy-plugin-remove` | 117 | only the closing status message |
| `omarchy-plugin-clone` | 149 | plugin discovery, `omarchy-plugin-enable`, notification, `exec $EDITOR` |
| `omarchy-plugin-add` | 149 | the enable prompt and `omarchy-plugin-enable` |

For update and remove the damage is limited to a wrong exit code and a misleading message. For add and clone the abort happens before the plugin is enabled, which would leave the plugin installed but disabled and skip the rest of the script. I measured the update case; the other three I read from the source rather than reproduced.

That last part looks like it may be the real mechanism behind #9304, which reports exactly that outcome for `omarchy plugin add --enable` and attributes it to the later `enablePlugin` call timing out. With `--enable --yes` both explanations produce identical output, so it may be worth checking which one fires there.

## Why the exit code matters beyond cosmetics

#10021 and #10326 both propose folding plugin updates into `omarchy update`, in unattended mode via `--yes`. A step that exits 1 after doing its job correctly would report the whole system update as failed.

## Suggested fix

`omarchy-shell` already has a flag for exactly this, described in its own help as "Quiet best-effort mode. Suppress output and return success even when the shell, target, method, or arguments are unavailable":

```bash
omarchy-shell -q shell rescanPlugins
```

Verified with the timeout forced short:

```
$ OMARCHY_SHELL_IPC_TIMEOUT=0.05s omarchy-shell shell rescanPlugins;    echo "exit=$?"
omarchy-shell is not responding
exit=1
$ OMARCHY_SHELL_IPC_TIMEOUT=0.05s omarchy-shell -q shell rescanPlugins; echo "exit=$?"
exit=0
```

`-q` is already the house style for best effort IPC in at least ten other commands (`omarchy-osd`, `omarchy-reminder`, `omarchy-theme-bg-set`, `omarchy-update-status` and others), but none of the six plugin scripts use it.

For `omarchy-plugin-add` and `omarchy-plugin-clone` a quiet failure alone is not enough, since they depend on the rescan having landed before they enable the plugin. Those two probably want a bounded wait rather than just swallowing the timeout, which is the same conclusion #9304 reaches.

## Reproduce

With enough plugins installed that a reload takes more than two seconds (9 git managed ones here):

```bash
# roll one plugin back so there is something to pull
git -C ~/.config/omarchy/plugins/<some-plugin> reset --hard HEAD^

omarchy plugin update --yes; echo "exit=$?"
# -> "Updated <id>." then "omarchy-shell is not responding", exit=1
# -> the checkout is correctly at origin, the plugin is loaded, ping answers ok
```

Setting `OMARCHY_SHELL_IPC_TIMEOUT=10s` makes the same run exit 0 and stay quiet.

## Environment

- omarchy 4.0.3-1, quickshell 0.3.1-1, Hyprland 0.56.2, Arch
- 10 plugins under `~/.config/omarchy/plugins/`, 9 of them git checkouts