## Cloning the bar plugin (`omarchy plugin clone omarchy.bar`) produces a bar that never renders

### What happened

Following the documented workflow for customizing the built-in status bar —
`omarchy plugin clone omarchy.bar`, then editing the clone — results in **no
status bar at all**. This reproduces with a byte-for-byte, unmodified copy of
the packaged `Bar.qml`, so it isn't specific to any particular edit; cloning
the bar plugin is broken in general.

### Expected behavior

A freshly cloned bar (before any edits) should render identically to the
built-in one, since that's the entire premise of "clone it, then customize."

### Steps to reproduce

1. `omarchy plugin clone omarchy.bar` (this also switches `bar.id` to the
   clone in `~/.config/omarchy/shell.json` automatically)
2. `omarchy restart shell`
3. Observe: the top bar disappears completely. `hyprctl layers` shows no
   `omarchy-bar` namespace surface at all (only `omarchy-background`), and
   `hyprctl monitors -j` shows `"reserved": [0,0,0,0]` — no exclusion zone is
   reserved.
4. Confirmed this also happens with a **pristine, untouched copy** of
   `/usr/share/omarchy/shell/plugins/bar/Bar.qml` placed at the clone's path —
   ruling out any customization as the cause.
5. Reverting `shell.json`'s `bar.id` back to the default (`omarchy.bar`, or
   removing the key) immediately restores the bar.

### Root cause (from `journalctl --user` and the Quickshell `log.qslog`)

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

`Bar.qml` (the file every clone starts from) declares its host-injected
properties as `required`:

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

For the **built-in** bar, `shell.qml` instantiates it through a `Component`
with property bindings supplied at construction time:

```qml
Component {
  id: defaultBarComponent
  Bar {
    omarchyPath: shell.omarchyPath
    barWidgetRegistry: shell.barWidgetRegistry
    barConfig: shell.barConfig
    shell: shell
    manifest: shell.barManifestFor(shell.defaultBarId)
  }
}
```

so the `required` properties are satisfied before the component finishes
constructing.

For a **cloned/custom** bar, `shell.qml` instead loads it generically:

```qml
Loader {
  id: pluginBarLoader
  active: !shell.pluginReloading && shell.activeBarId !== shell.defaultBarId && shell.activeBarSourceUrl !== ""
  source: shell.activeBarId !== shell.defaultBarId ? shell.activeBarSourceUrl : ""
  asynchronous: true
  onLoaded: shell.configureBar(item, shell.activeBarManifest)
  onStatusChanged: {
    if (status === Loader.Error) {
      var detail = errorString && errorString() ? errorString() : ""
      console.warn("bar option " + shell.activeBarId + " failed to load, falling back to " + shell.defaultBarId + ":", detail)
      shell.failedBarId = shell.activeBarId
    }
  }
}
```

Here, `configureBar()` (which assigns `omarchyPath`/`barWidgetRegistry`/
`barConfig`) only runs in `onLoaded` — **after** the component has already
finished constructing. Since those three properties are `required`, QML fails
component completion before `onLoaded` can ever fire, so the Loader's status
becomes `Loader.Error` and the bar never mounts. Any bar plugin cloned from
the shipped template inherits this and is unloadable as-is.

This is compounded by a second, independent bug in the same block: the error
handler references a bare `errorString` identifier that doesn't exist in this
scope (`shell.qml:256`), throwing `ReferenceError: errorString is not
defined` instead of logging the real cause. That masks the actual "required
property not initialized" diagnostic, so a user (or anyone debugging this)
has no indication of why the bar silently vanished.

### Suggested fix

Either (or both):

1. Have `pluginBarLoader` supply the host-injected properties at construction
   time instead of in `onLoaded` — e.g. via `Qt.createComponent(...).
   createObject(parent, { omarchyPath: ..., barWidgetRegistry: ..., barConfig:
   ... })` — so `required` properties on a cloned `Bar.qml` are satisfied
   before completion, matching how the built-in bar is instantiated.
2. Fix the `onStatusChanged` handler at `shell.qml:256` to reference whatever
   actually reports the Loader's failure reason, so a broken custom bar logs
   a useful diagnostic instead of a `ReferenceError`.

### Workaround

Editing the clone's `Bar.qml` to make the three properties non-required with
safe defaults gets a cloned bar working again:

```qml
property string omarchyPath: ""
property var barWidgetRegistry: null
property var barConfig: null
```

(plus guarding any code that dereferences `barWidgetRegistry` before
`configureBar()` populates it, e.g. `if (!root.barWidgetRegistry) return
null` in `ModuleSlot.registryComponent`). This isn't something a user should
have to do just to follow the documented "clone the bar to customize it"
workflow.

### System details

- Omarchy: 4.0.1-1
- Hyprland: 0.56.2
- Quickshell: 0.3.1
- Kernel: 7.1.9-arch1-2
- CPU: Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz
- GPU: Intel Iris Plus Graphics G1 (Ice Lake)