## What happened

After updating Omarchy 4.0.2 -> 4.0.3, a **cloned menu plugin** (e.g. a user clone of `omarchy.menu` such as `ebinalex.menu`) opens with an **empty apps submenu**. The apps section shows "Nothing here yet" instead of the installed desktop applications.

First-party built-in menus are unaffected.

## Expected vs actual

- **Expected:** the apps submenu lists desktop applications (with icons), same as 4.0.2.
- **Actual:** the apps submenu renders no rows. The enclosing menu still opens and renders (so it is not a rendering/summon failure), but the app rows are missing.

## Environment

- Omarchy `4.0.3-1` (quickshell `0.3.1-1`)
- Hyprland session via uwsm
- Reproduced with a cloned menu plugin: `id: ebinalex.menu`, `omarchy.clonedFrom: omarchy.menu`, `kinds: ["menu", "bar-widget"]`, `keepLoaded: true`

## Steps to reproduce

1. Clone a built-in menu plugin (e.g. `ebinalex.menu` from `omarchy.menu`) so it becomes the enabled menu.
2. Open the menu and select the apps section.
3. Observe the empty app list.

## Root cause diagnosis

Traced at runtime (`shell call <id> debugApps` + instrumented `shell.qml`):

- `computePanelEntries()` copies each plugin manifest out of `pluginRegistry.installedPlugins` into the `panelEntries` model property.
- The `Instantiator` delegate exposes it via `modelData.manifest`, which converts the manifest's nested `kinds` JS array into a **QVariantList**. On the panel-loader path `Array.isArray(manifest.kinds)` is `false`.
- `manifestHasKind()` only accepts real JS arrays, so the panel loader's `pluginShellFor(panelEntry.manifest)` (in the loader `onLoaded`) computes a different capability profile (`own-service|no-bar|no-indicators|no-menu`) than the earlier `menu` profile for the same plugin id.
- `createScopedPluginShell()` therefore **revokes the cached PluginShellApi that carries `appLibrary`** and creates a new one without it. That appLibrary-less shell is injected into the menu plugin, and `mergeAppRows()` early-returns on the missing app library → empty app list.

Observed logs during diagnosis:

```
DBG createScopedPluginShell(ebinalex.menu) ... isArr=true ... idxMenu=0 ... hasMenuKind=true   profile=...|menu
DBG SITE panelLoader id=ebinalex.menu kindsArr=false
DBG createScopedPluginShell(ebinalex.menu) ... isArr=false ... hasMenuKind=false              profile=...|no-menu
```

## Suggested fix (minimal, one function)

Make `manifestHasKind()` tolerant of array-like `kinds` values (QVariantList), so the profile stays consistent regardless of which path the manifest took:

```qml
function manifestHasKind(manifest, kind) {
  if (!manifest) return false
  var kinds = manifest.kinds
  if (Array.isArray(kinds)) return kinds.indexOf(kind) !== -1
  if (kinds && typeof kinds === "object" && typeof kinds.length === "number") {
    for (var i = 0; i < kinds.length; i++)
      if (String(kinds[i]) === kind) return true
    return false
  }
  return false
}
```

Verified to restore the app list (52 entries; icons render) in the affected clone.