### Description

`reloadPlugins()` tears down and re-initialises **every installed plugin** when **one** plugin changes. `shell.qml`:

```qml
function reloadPlugins() {
  ...
  shell.unloadPanels(); shell.unloadPluginServices(); shell.unloadPluginWidgets()
  Qt.callLater(shell.finishPluginReload)     // -> Qt.clearComponentCache(); pluginRegistry.rescan()
}
```

This is **not** the same report as #12158, #11929, #12020 or #12189. Those all narrow *when* a reload fires (filtering caches, bytecode, non-loadable paths) and are worth merging on their own. This is about what a reload *costs* once it legitimately fires — which none of them change.

### Measured cost of a single legitimate reload

Editing one `.qml` in one plugin, with PR #12189's whitelist already applied locally so the trigger is unambiguously a real source edit:

| | |
|---|---|
| processes spawned | **502** |
| peak spawn rate | **102/sec** (idle baseline: 7/sec) |
| duration | 5–8 s |

Because every plugin re-runs its startup path, a single edit collectively executes:

- `checkupdates` → `pacman -Sy`, plus `pacman -Qq` / `-Qi` / `-Qu` / `-Qoq`
- `git ls-remote https://github.com/openai/plugins.git` (codex agent-usage collector, cf. #12411)
- `curl wttr.in` and `curl api.open-meteo.com`
- `magick` re-decoding a 2880px wallpaper
- `podman info`, `podman ps`, `docker context inspect`, `rustup component list`, `flatpak` ×12, `lspci` ×4, `nmcli`, `pw-dump`

### Why it presents as a freeze

The stall is memory, not CPU or GPU. The spawn burst drives `kswapd0` to ~67% compressing into zram, and **memory PSI `full` peaked at 230 ms/s** — i.e. for ~23% of that second *every task on the machine* was blocked on memory. Hyprland's main thread logged 462 ms CPU and 75 ms runqueue wait in the same second.

Notably, compositor frame delivery stays clean throughout (measured with a layer-shell frame probe: ~100% of vblanks hit, zero frames >25 ms). The compositor keeps presenting on time while *applications* are starved, so it reads to the user as UI stutter with no obvious cause.

### Why narrowing the trigger isn't sufficient

Plugin development happens in `~/.config/omarchy/plugins/`, the documented location. Every save of a `.qml` is a legitimate trigger and still costs ~500 processes. In a 30-minute window on this machine the shell logged **108** `Local plugin changed` events (90 from a C++ plugin's build, 18 from editing a plugin's scripts).

The existing `keepLoaded` flag — which exists so the lock screen, idle handler and polkit agent survive a reload — suggests the destructiveness of the global teardown was already felt, and was addressed with a per-service opt-out rather than by scoping the reload.

### Suggested directions

1. **Scope the reload to the changed plugin.** The blocker is that `Qt.clearComponentCache()` is process-global with no per-URL variant, so this likely needs plugin QML loaded through separate engines/`QQmlComponent` ownership to be unloadable independently.
2. **Treat plugin init as a cold path.** A plugin's `Component.onCompleted` should not run `pacman -Sy` or a network round-trip. Cached-with-TTL results, and a first paint that renders from cache, would cut the cost by most of its magnitude even with the global reload retained.
3. **Bound concurrency.** Nothing currently caps how many subprocesses a reload may spawn at once; ~500 land within a couple of seconds.
4. Raise the 150 ms debounce in `localPluginReloadTimer` — shorter than an editor's or compiler's write burst.

### Environment

omarchy 4.0.4-1 · Hyprland 0.56.2 · Quickshell 0.3.1 · Arch, kernel 7.2.3 · 15 GiB RAM, zram swap (zstd)

Counts from `/proc` sampling at 20 Hz; reload events from `journalctl -t omarchy-shell | grep "Local plugin changed"`.