## What happened

Cloning the built-in bar plugin via the documented workflow (`omarchy plugin clone omarchy.bar`) and switching `shell.json`'s `bar.id` to the clone breaks the shell entirely — the bar disappears from every monitor until `bar.id` is reverted back to `omarchy.bar` and the shell is restarted.

The journal shows:

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

No config edits were made to `Bar.qml` before this happened — it reproduces on a byte-for-byte clone.

## What was expected

A plain clone of the built-in bar plugin, activated the documented way, should render identically to the built-in bar.

## Steps to reproduce

1. `omarchy plugin clone omarchy.bar` (this clones the plugin and switches `~/.config/omarchy/shell.json`'s `bar.id` to the new clone automatically).
2. `omarchy restart shell` (or wait for the hot-reload triggered by the clone).
3. The bar vanishes on every monitor. `journalctl --user` shows the required-property warnings and the `ReferenceError` above.

## Root cause (found while reading `shell.qml`)

`shell/plugins/bar/Bar.qml` declares three required properties:

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

The built-in bar is instantiated through `defaultBarComponent` in `shell.qml`, which binds these inline at creation time:

```qml
Component {
  id: defaultBarComponent
  Bar {
    omarchyPath: shell.omarchyPath
    barWidgetRegistry: shell.barWidgetRegistry
    barConfig: shell.barConfig
    ...
  }
}
```

But a custom/cloned bar goes through `pluginBarLoader` instead — a `Loader { source: shell.activeBarSourceUrl }` — which creates the object with no initial properties and only assigns them afterward via `onLoaded: shell.configureBar(item, ...)`. Because the three properties are `required`, object creation fails synchronously before `configureBar()` ever runs, and `pluginBarLoader.status` becomes `Loader.Error`.

That failure then hits a second bug in the same file — the `onStatusChanged` error handler references a bare `errorString` identifier instead of the loader's own `errorString()`:

```qml
onStatusChanged: {
  if (status === Loader.Error) {
    var detail = errorString && errorString() ? errorString() : ""  // ReferenceError here
    ...
```

so even the "fall back to the default bar" diagnostic path throws.

Net effect: the custom-bar plugin mechanism (`"kinds": ["bar"]` + `shell.json`'s `bar.id`) appears to be non-functional for any plugin that doesn't happen to dodge these two bugs — including a stock, unmodified clone of the built-in bar made via the officially documented `omarchy plugin clone` command.

## Suggested fix

- Supply the required properties at creation time for the custom-bar Loader too (e.g. `Loader.setSource(url, {omarchyPath, barWidgetRegistry, barConfig})`, or drop `required` from those three properties in `Bar.qml` and rely on `configureBar()` to populate them immediately after, as the default-bar path effectively already does for `shell`/`manifest`).
- Fix the `errorString` reference in `pluginBarLoader.onStatusChanged` to call the loader's own `errorString()`.

## System details

- Omarchy: 4.0.2-1
- Kernel: Linux 7.1.9-arch1-2 x86_64
- Hyprland: 0.56.2
- Quickshell: 0.3.1-1
- GPU: AMD Radeon RX 5600 XT (Navi 10)