## What happened

Cloning the built-in `bar`-kind plugin (`omarchy plugin clone omarchy.bar --edit`, or `--edit` omitted — same result) and activating the clone via `shell.json`'s `bar.id` results in **no bar panel appearing at all** — not even the original bar's geometry, just nothing. This reproduces with a byte-identical, completely unmodified clone, so it isn't specific to editing the clone's `Bar.qml`.

## Expected

The cloned bar should render identically to the built-in one (that's the entire point of `omarchy plugin clone <kind:bar id>` — it's the documented, sanctioned way to customize the bar).

## Steps to reproduce

```bash
omarchy plugin clone omarchy.bar
# -> "Cloned omarchy.bar to ~/.config/omarchy/plugins/<user>.bar and switched to <user>.bar"
omarchy restart shell
```

Then check for the bar's layer-shell surface:

```bash
hyprctl layers -j | jq '.[].levels | .. | objects | select(.namespace? == "omarchy-bar")'
```

Result: empty — no `omarchy-bar` namespace surface exists on any monitor, even though `omarchy plugin list` correctly shows the clone as the sole `enabled` bar-kind plugin and the built-in one as `disabled`. `hyprctl monitors -j` also confirms the reserved exclusion zone stays `[0, 0, 0, 0]` (no space reserved for the bar).

Reverting `shell.json`'s `bar.id` back to `omarchy.bar` (with the clone still present but inactive) immediately restores the bar with correct geometry — confirming the built-in bar and the shell's plugin-loading machinery are otherwise fine, and the problem is specific to the "clone-and-activate" path for `kind: bar` plugins.

## Diagnostics

`journalctl --user -b` around the reload shows the clone's `Bar.qml` root item receiving its required properties as expected (`omarchyPath`, `barWidgetRegistry`, `barConfig` — transient "not initialized" warnings during the reload itself, same as seen on every hot-reload), but also this, which looks like the actual smoking gun:

```
WARN scene: QML IpcHandler at @plugins/bar/Bar.qml[955:3]: Handler was registered but will not be used because another handler is registered for target omarchy.bar
```

This says the **built-in** `@plugins/bar/Bar.qml` is still being instantiated (its `IpcHandler { target: "omarchy.bar" }` registers) even while `omarchy plugin list` reports it as `disabled` and the clone as the only enabled `bar`-kind plugin. It looks like the plugin registry may preload/cache the first-party `bar` kind's QML component regardless of enabled state, and something about that collides with the clone taking over the `kind: bar` slot, leaving neither panel actually mapped.

No QML parse/type errors are logged for the clone's file — the file loads and evaluates without exception, just never produces a mapped `PanelWindow`.

`omarchy-shell shell rescanPlugins` does not fix it; a full `omarchy restart shell` does not fix it either.

## System details

- `omarchy version`: 4.0.2-1
- `quickshell`: 0.3.1-1
- `qt6-declarative`: 6.11.2-1
- Hyprland: 0.56.2 (v0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f)
- Kernel: `7.1.9-arch1-2`
- Bar config: `position: "left"` (vertical bar), single laptop panel monitor (eDP-1, 1366x768)

(Note: `omarchy debug --no-sudo --print` from the docs is not a recognized command on this `omarchy` version — `omarchy commands --all` doesn't list a `debug` group — so I couldn't attach that log; happy to provide anything else needed.)