Make the closing plugin rescan best-effort

[Mario-Mohar]

Fixes #11115.

The problem

All four plugin commands run under set -euo pipefail and end by telling the shell to reload:

omarchy-shell shell rescanPlugins >/dev/null

omarchy-shell wraps every call in timeout ${OMARCHY_SHELL_IPC_TIMEOUT:-2s} and exits 1 on expiry. The reload this line triggers is exactly the thing that can take longer than two seconds, so the command aborts on its own last request. >/dev/null only covers stdout, so omarchy-shell is not responding still reaches the terminal.

Measured on a machine with 9 git managed plugins: a rescan with nothing to reload takes 0.05 s, one right after a real plugin update takes 1.65 s, and a second one arriving while the first is still rebuilding hits the 2 s limit. The rescan itself always completes. Only the client gives up.

What that costs depends on what follows the call:

command	line	what an abort costs
omarchy-plugin-update	131	exit 1 after every plugin was fast forwarded correctly
omarchy-plugin-remove	117	exit 1 after the plugin was removed
omarchy-plugin-add	149	the enable decision never runs; plugin installed but disabled, and no "enable it later with" line
omarchy-plugin-clone	149	discovery, enable, notification and the closing message never run

The exit code is not only cosmetic. #10021 and #10326 both want plugin updates to run from omarchy update, unattended. A step that exits 1 after doing its job would report the whole system update as failed.

The add and clone rows may also be the real mechanism behind #9304, which reports a plugin landing installed but disabled and attributes it to the later enablePlugin call. With --enable --yes both paths produce the same output, so it is worth checking which one fires there. This PR does not close that issue.

The change

omarchy-shell -q shell rescanPlugins

-q is described in omarchy-shell's own help as "Quiet best-effort mode. Suppress output and return success even when the shell, target, method, or arguments are unavailable", and it is already how ten other commands make best-effort IPC calls (omarchy-osd, omarchy-reminder, omarchy-theme-bg-set, omarchy-update-status among them). None of the six plugin commands used it. It also covers stdout, so the >/dev/null goes with it.

The call is still made. Only its failure stops being fatal.

Testing

New test/shell.d/plugin-rescan-test.sh. Its omarchy-shell stub reproduces the real one: without -q it prints omarchy-shell is not responding and exits 1, with -q it exits 0 silently. Six assertions covering all four commands, plus one that counts the logged rescans so best effort cannot quietly become no effort.

Each of the four fixes was reverted on its own to confirm the test fails without it, and fails on the matching assertion:

only omarchy-plugin-update reverted -> exit=1  not ok - plugin update survives a rescan that times out
only omarchy-plugin-remove reverted -> exit=1  not ok - plugin remove survives a rescan that times out
only omarchy-plugin-add    reverted -> exit=1  not ok - plugin add survives a rescan that times out
only omarchy-plugin-clone  reverted -> exit=1  not ok - plugin clone survives a rescan that times out

./test/all before and after this change fails the same 6 of its test files, none of them plugin related: config, locate, runtime-smoke, screenshot-sanity, snapper, unowned-system-paths. They want an omarchy-pkgs checkout or a live compositor, neither of which this machine has. The file count goes from 236 to 237 with the new test.

Also verified against the running desktop: omarchy plugin update with two real plugins behind their origin exits 0 and stays quiet, where before it printed the error and exited 1.