### What happened

Cloning `omarchy.media` with `omarchy plugin clone` leaves the bar widget permanently blank. There is no error, no warning in the Quickshell log, and `omarchy plugin list` reports the clone as enabled — the slot just renders nothing.

The cause is that `shell.firstPartyServiceFor()` does not resolve `omarchy.clonedFrom`, while the panel entry points do.

### Steps to reproduce

```bash
omarchy plugin clone omarchy.media
```

Then play anything that exposes MPRIS (a browser tab is enough).

**Expected:** the cloned widget behaves exactly like `omarchy.media` did before cloning.
**Actual:** the widget is invisible. Playback controls, media OSD and the popup are all gone.

### Why

`omarchy-plugin-clone` deliberately keeps the built-in id inside the plugin's code:

> Keep built-in ids inside the plugin code as stable IPC targets. The shell uses `clonedFrom` to route those calls to this local manifest id.

So the cloned `BarWidget.qml:10` still asks for the built-in id:

```qml
readonly property var mediaService: bar?.shell?.firstPartyServiceFor("omarchy.media")
```

But that routing only exists for panels. `PluginRegistry.resolveEnabledId()` is called from exactly five places in `shell.qml` — `summon` (441), `hide` (481), `isPluginOpen` (498), `toggle` (511) and `callIfLoaded` (568). Service lookup is a plain map read:

```qml
// shell.qml:275
function serviceFor(pluginId) {
  return _services[String(pluginId)] || null
}

// shell.qml:279
function firstPartyServiceFor(pluginId) {
  return serviceFor(pluginId)
}
```

`_services` is keyed by manifest id (`ensureService(id)`, `shell.qml:333`), so after cloning the instance lives under `<user>.media`, while the widget asks for `omarchy.media` and gets `null`.

It fails silently because the widget's visibility derives from the service:

```qml
readonly property bool hasMedia: activePlayer !== null && (...)
visible: hasMedia          // null service -> false -> empty slot
```

Cloning also auto-disables the source (`PluginRegistry.qml:523`), so there is no surviving `omarchy.media` service to fall back to — which is correct, and not the problem.

### Scope

`omarchy.media` is currently the only first-party plugin declaring both `service` and `bar-widget`:

```bash
for f in /usr/share/omarchy/shell/plugins/*/manifest.json /usr/share/omarchy/shell/plugins/*/*/manifest.json; do
  jq -r 'select((.kinds|index("service")) and (.kinds|index("bar-widget"))) | .id' "$f" 2>/dev/null
done | sort -u
# omarchy.media
```

So this affects any clone of a plugin that is both a service and a bar widget, which today means `omarchy.media` and any third-party plugin shaped the same way.

### Suggested fix

Route service lookup through the same resolver the panel paths already use:

```qml
function serviceFor(pluginId) {
  var id = pluginRegistry ? pluginRegistry.resolveEnabledId(pluginId) : String(pluginId)
  return _services[String(id)] || null
}
```

`resolveEnabledId` already returns the id unchanged when no enabled clone exists, so this is a no-op for the uncloned case.

As a workaround, a clone can ask for both ids:

```qml
readonly property var mediaService: {
  var s = bar ? bar.shell : null
  if (!s || typeof s.firstPartyServiceFor !== "function") return null
  return s.firstPartyServiceFor("<user>.media") || s.firstPartyServiceFor("omarchy.media") || null
}
```

### Environment

- Omarchy `4.0.2-1`
- Quickshell `0.3.1` (Arch package)
- Hyprland `0.56.2`

No hardware-specific diagnostics attached: this is a pure control-flow bug in `shell.qml` / `PluginRegistry.qml` and reproduces from the two commands above on any machine. Happy to add a full `omarchy debug` log if useful.