Updating a plugin reloads its bar widget but keeps its panel QML from the component cache

The README says:

> Saving a file anywhere under `~/.config/omarchy/plugins/` reloads plugin code
> automatically; `omarchy-shell shell rescanPlugins` remains available to force a reload.

For a plugin's bar widget that holds. For the panel QML it does not: the shell logs
`Local plugin changed, reloading` and rebuilds the widget, but the panel component stays
in the QML engine's in-memory component cache and the old code goes on running until
`omarchy restart shell`. `omarchy plugin update`, which calls `rescanPlugins`, has the
same gap, so the documented update path leaves the user running the previous version
with no indication that anything is stale.

### Why it is more than cosmetic

The failure is silent and actively misleading. A user who updates a plugin specifically
to pick up a fix sees the bug persist, and the shell log points at the *new* file with
line numbers from the *old* one.

Concretely, from this machine earlier today. A plugin was updated from 0.4.1 to 0.4.2 at
12:29:15; the shell had been running since 10:22:33. The shell noticed the change:

```
DEBUG qml: Local plugin changed, reloading: io.github.itsmoorgrove.protoncalendar
```

and then logged this 20 times over the following minutes, while 0.4.2 was on disk:

```
WARN scene: file:///home/.../protoncalendar/Panel.qml[138:-1]: TypeError:
Cannot assign to read-only property "centerHoverRevealSuppressed"
```

Line 138 of the file on disk at that moment (0.4.2) is:

```qml
      root.bar.setCenterHoverRevealSuppressed(value)
```

a function call, which cannot raise that error. Line 138 of the *previous* version is:

```qml
      root.bar.centerHoverRevealSuppressed = value
```

So the engine was executing the old compiled unit while reporting positions against a
file it was no longer running. Anyone debugging from that log is chasing a line that
already contains the fix. `omarchy restart shell` cleared it immediately.

### Reproduce

1. Install any plugin that provides a panel, and open the panel once so the component is
   instantiated and cached.
2. Change its panel QML — `omarchy plugin update`, or just edit the file in place.
3. Open the panel again. The old behaviour is still there; the log shows
   `Local plugin changed, reloading` but the panel is unchanged.
4. `omarchy restart shell`. The change appears.

Step 1 matters: the panel has to have been instantiated at least once for a stale copy
of it to be held. I have reproduced the cached case reliably; I have not separately
confirmed what happens when the panel was never opened before the change.

### Suggestion

Either drop the cached component on `rescanPlugins` so the documented hot-reload covers
panel QML as well as widgets, or, if that is not practical, have `omarchy plugin update`
say that a shell restart is needed and soften the README claim. The current combination
of a promise of automatic reload, a log line saying it reloaded, and stale code running
is the part that costs people time.

Happy to test a patch.

### Versions

- omarchy 4.0.4-1 (`/usr/share/omarchy/version` reads `4.0.0.alpha`)
- quickshell 0.3.1-1
- Hyprland v0.56.2
- Arch