## What's wrong

`omarchy plugin disable <unknown-id>` exits 0 and reports success without disabling anything, unlike `omarchy plugin enable <unknown-id>`, which fails loudly with the correct error message. A user who typos a plugin id (or copies one from stale documentation — this is exactly how I found it, via a third-party plugin's README) gets told the plugin was disabled when it was not, and has no indication anything went wrong.

Reproduced against a real installed plugin (`macos.dock`) with a typo'd id:

```
$ omarchy plugin enable ifubaraboye.dock
omarchy-plugin-enable: plugin 'ifubaraboye.dock' is not known; run: omarchy-shell shell rescanPlugins

$ omarchy plugin disable ifubaraboye.dock
Disabled ifubaraboye.dock

$ omarchy plugin list | grep dock
macos.dock                       enabled   third-party panel              macOS Style Dock
```

`enable` refuses correctly. `disable` claims success against an id that has never existed, and the real plugin (`macos.dock`) stays enabled throughout — the command that looked like it worked did nothing at all.

## Root cause

`PluginRegistry.setEnabled()` (`shell/services/PluginRegistry.qml`) validates the manifest only on the enable path:

```qml
function setEnabled(id, value, placement) {
    var key = Util.canonicalWidgetId(String(id))
    lastEnableError = ""
    if (!shellConfigMutator) {
      console.warn("PluginRegistry.setEnabled called before shellConfigMutator wired")
      return false
    }
    var manifest = installedPlugins[key]
    if (value && !manifest) {
      console.warn("PluginRegistry.setEnabled: unknown plugin " + key)
      return false
    }
    ...
```

`if (value && !manifest)` only fires when `value` is `true` (enabling). For `value = false` (disabling), an unknown id skips this guard entirely and falls through to the same code path a real, currently-enabled plugin would take, which apparently still reports success.

The two CLI scripts show the same asymmetry one level up. `omarchy-plugin-enable` checks for both outcomes:

```bash
result=$(omarchy-shell shell enablePlugin "$id" "$placement")
if [[ $result == "unknown" ]]; then
  fail "plugin '$id' is not known; run: omarchy-shell shell rescanPlugins"
elif [[ $result != "ok" ]]; then
  fail "$result"
fi
```

`omarchy-plugin-disable` only checks for one:

```bash
result=$(omarchy-shell shell setPluginEnabled "$id" false)
[[ $result == "ok" ]] ||
  fail "plugin '$id' is not known; run: omarchy-shell shell rescanPlugins"
```

The `shell.qml` IPC handler behind it already returns the right signal for this exact case, so the fix looks like it lives in `PluginRegistry.setEnabled()` alone:

```qml
function setPluginEnabled(id: string, enabled: string): string {
  return shell.pluginRegistry.setEnabled(id, enabled === "true") ? "ok" : "unknown"
}
```

## Suggested fix

Change the guard in `setEnabled()` from `if (value && !manifest)` to `if (!manifest)`, so both enable and disable reject an unrecognized id the same way. `omarchy-plugin-disable`'s existing `[[ $result == "ok" ]] || fail ...` already produces the right message once `setEnabled` returns `false` for this case — no CLI-side change needed.

## Environment

Omarchy 4.0.3-1, quickshell 0.3.1-1.