## What happened

`omarchy plugin disable` reports success for a plugin id that does not exist:

```
$ omarchy plugin disable does.not.exist; echo "exit=$?"
Disabled does.not.exist
exit=0
```

Nothing happens. A typo in the id is indistinguishable from a real disable, so the plugin the user meant to switch off keeps running while the command says it was switched off.

The IPC call underneath answers `ok`, and `shell.json` is untouched:

```
$ md5sum ~/.config/omarchy/shell.json
cf10e466fd4e1c2e617b6f423b8be9fa  /home/.../shell.json
$ omarchy-shell shell setPluginEnabled totally.made.up false
ok
$ md5sum ~/.config/omarchy/shell.json
cf10e466fd4e1c2e617b6f423b8be9fa  /home/.../shell.json
```

The enable side of the same registry call gets this right:

```
$ omarchy-shell shell enablePlugin totally.made.up '{}'
unknown
```

## Where it comes from

Both IPC handlers go through `PluginRegistry.setEnabled` (`shell/shell.qml:1609` and `:1613`), and the guard there only covers one direction (`shell/services/PluginRegistry.qml:482`):

```javascript
var manifest = installedPlugins[key]
if (value && !manifest) {
  console.warn("PluginRegistry.setEnabled: unknown plugin " + key)
  return false
}
```

With `value` false the guard is skipped, the disable path finds no `clonedFrom`, no bar layout entry and no `plugins[]` entry, so it changes nothing, and the function still ends on:

```javascript
if (lastEnableError) return false
registryRevision++
pluginsChanged()
return true
```

`true` becomes `ok` in `setPluginEnabled`, and `omarchy-plugin-disable` prints `Disabled $id` on anything that is not a non-`ok` answer. There is no `console.warn` on this path either, so nothing is left in the log.

## The guard's asymmetry looks deliberate

I am guessing here, but refusing an unknown id on the disable side would be wrong: a plugin whose directory was deleted has no manifest while its `shell.json` entry is still there, and that entry has to stay removable. So the fix is probably not to widen the guard to `!manifest`, but to make the return value say whether anything was actually found. Disabling an id with neither a manifest nor a config entry is the case that should answer `unknown`, and that keeps the ghost-entry cleanup working.

Nothing in `test/shell.d/` currently covers `setEnabled` with an unknown id in either direction, so there is no existing expectation to weigh this against.

## A smaller side effect

The same path runs `registryRevision++` and `pluginsChanged()` before returning, so a call that changed nothing still signals every consumer that the plugin set moved.

## Reproduce

```bash
omarchy plugin disable some.id.that.does.not.exist   # prints "Disabled ...", exits 0
omarchy-shell shell setPluginEnabled some.id.that.does.not.exist false   # ok
omarchy-shell shell enablePlugin some.id.that.does.not.exist '{}'        # unknown
```

## Environment

- omarchy 4.0.3-1, quickshell 0.3.1-1, Hyprland 0.56.2, Arch
- Found while testing #11118; unrelated to that change, and present without it.