**Omarchy version:** 4.0.0-1
**Hyprland:** 0.56.2
**Shell:** omarchy-shell (Quickshell), 2 monitors

### What happened

`omarchy plugin clone omarchy.bar` succeeds and switches `bar.id` to the clone,
but the clone never loads. The result is **no bar on any monitor** — the
`omarchy-bar` layer surface is gone entirely — with nothing printed to explain
it and no fallback to the built-in bar.

```
$ omarchy plugin clone omarchy.bar
Cloned omarchy.bar to /home/koen/.config/omarchy/plugins/koen.bar and switched to koen.bar

$ hyprctl layers | grep -E 'Monitor|omarchy-bar'
Monitor HDMI-A-1:
Monitor DP-1:
```

The journal shows the cause, though nothing surfaces it to the user:

```
WARN scene: file:///home/koen/.config/omarchy/plugins/koen.bar/Bar.qml[22:3]:
  Required property barConfig was not initialized
WARN scene: file:///home/koen/.config/omarchy/plugins/koen.bar/Bar.qml[15:3]:
  Required property omarchyPath was not initialized
WARN scene: file:///home/koen/.config/omarchy/plugins/koen.bar/Bar.qml[17:3]:
  Required property barWidgetRegistry was not initialized
WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined
```

### What I expected

The cloned bar loads and renders, since cloning a first-party plugin to
customise it is the documented workflow.

Failing that, the documented fallback should kick in: `shell.qml` sets
`shell.failedBarId` on `Loader.Error` specifically so a broken bar option falls
back to `omarchy.bar`. It never runs.

### Steps to reproduce

1. `omarchy plugin clone omarchy.bar`
2. `omarchy restart shell`
3. No bar on any monitor. `hyprctl layers` shows no `omarchy-bar` surface.
4. Recover with `omarchy bar use omarchy.bar` (or delete the clone) and
   `omarchy restart shell`.

### Root cause

Two independent defects, the second of which hides the first.

**1. `shell/plugins/bar/Bar.qml` declares injected properties as `required`.**

```qml
required property string omarchyPath
required property var barWidgetRegistry
required property var barConfig
```

QML will not instantiate a component whose `required` properties are unset.
`shell.qml` has two paths to a bar:

- `defaultBarComponent` passes all three declaratively, so the built-in bar is fine.
- `pluginBarLoader` sets `source:` and injects afterwards, in
  `onLoaded: shell.configureBar(item, ...)`.

The second can never work: the Loader fails before `onLoaded`, and
`configureBar()` opens with `if (!target) return`, so it is a no-op. Every bar
plugin is therefore unloadable, including a clone of the built-in bar.

This also makes `Bar.qml` the only plugin entry point using `required`.
`agents/skills/shell-dev.md` states entry points "accept the shell-injected
properties `omarchyPath`, `shell`, `manifest`, and `pluginRegistry` /
`barWidgetRegistry`", and `menu/Menu.qml` and `notifications/Service.qml` both
declare them plain with defaults — as do `Bar.qml`'s own `shell` and `manifest`.

**2. `shell/shell.qml` reads `errorString`, which does not exist on `Loader`.**

```qml
onStatusChanged: {
  if (status === Loader.Error) {
    var detail = errorString && errorString() ? errorString() : ""
    console.warn("bar option " + ... + ":", detail)
    shell.failedBarId = shell.activeBarId   // never reached
  }
}
```

The `ReferenceError` aborts the handler before `failedBarId` is set, so the
fallback to the built-in bar never happens and the warning is never printed.
That is why the failure presents as a silently missing bar.

### Suggested fix

Declare the three properties plain with defaults, matching the plugin contract
and every other entry point, and drop the `errorString` reference so the
existing fallback can run. Verified on this machine: with the properties
relaxed, a cloned bar loads and renders normally, and the built-in bar is
unaffected because `defaultBarComponent` still passes all three declaratively.

I have a branch with both fixes (8 insertions, 5 deletions across the two
files) and can open a PR.