## What happened

Third-party shell plugins declaring `"kinds": ["service", ...]` (tested with
`njpatel.omapager` and `nosignal.omasend`) are reported as `"enabled": false`
by `omarchy plugin list --json`, even though:

- They are correctly listed in `~/.config/omarchy/shell.json`'s `plugins[]`
  array, in the exact same `{"id": "..."}` shape as another third-party
  plugin (`bobbynicholas.omaland`) that correctly reports `"enabled": true`.
- Running `omarchy plugin enable <id>` reports success (`Enabled <id>`) and
  exits 0, but leaves `shell.json` byte-for-byte unchanged and does not
  change the reported `enabled` status.
- `omarchy-shell shell rescanPlugins`, run after the above, doesn't change
  the status either.
- Despite all of this, the plugins are demonstrably running and fully
  functional: `hyprctl layers` shows live layer-shell surfaces for both
  (`namespace: omapager`, `namespace: omarchy-omasend`), their IPC targets
  respond correctly (`omarchy-shell omapager count` -> `0`), and omapager
  has been actively handling real desktop notifications throughout testing.

So the `enabled` field in `omarchy plugin list` / `omarchy-shell shell
listPlugins` does not reflect whether the plugin is actually loaded and
running for at least these two plugins, and the `enable` subcommand is a
no-op for them.

## What I expected

Either:
- `enabled: true` once a plugin is present in `plugins[]` and not in
  `disabledPlugins[]` (matching the behavior seen for `bobbynicholas.omaland`
  and matching what the plugin is actually doing at runtime), or
- If `enabled: false` is intentional for some other reason, `omarchy plugin
  enable <id>` should either fix it or explain why it can't.

## Steps to reproduce

```bash
git clone https://github.com/njpatel/omapager.git ~/.config/omarchy/plugins/njpatel.omapager
# add {"id": "njpatel.omapager"} to shell.json's "plugins" array
omarchy restart shell
omarchy plugin list --json | jq '.[] | select(.id=="njpatel.omapager")'
# -> "enabled": false

omarchy plugin enable njpatel.omapager
# -> "Enabled njpatel.omapager", exit 0
omarchy plugin list --json | jq '.[] | select(.id=="njpatel.omapager")'
# -> still "enabled": false, shell.json unchanged

# yet:
hyprctl layers | grep omapager
# -> a real, live layer-shell surface
omarchy-shell omapager count
# -> 0 (a valid, live IPC response)
```

Same result with `nosignal.omasend` (id: `nosignal.omasend`), installed via
the plugins.omarchy.org listing rather than a direct git clone — its plugin
directory has no `.git` remote and its manifest lists no source URL, so I
can't point to its repo here, but the id/author match the marketplace entry.

## What I looked at

I traced this partway into `PluginRegistry.qml`'s `isEnabled()`:

```js
function isEnabled(id) {
    var key = String(id)
    var manifest = installedPlugins[key]
    var config = shellConfigProvider ? shellConfigProvider() : null
    if (manifest) {
      if (Array.isArray(manifest.kinds) && manifest.kinds.indexOf("bar") !== -1) {
        ...
      }
      if (isDisabled(config, key)) return false
      if (manifest.__isFirstParty) return true
    }
    return findEntryLocation(config, key).found
}
```

For both affected plugins: they're not a `"bar"`-kind plugin, they're not in
`disabledPlugins`, they're not first-party, and `findEntryLocation` (which
checks `config.plugins[]` for a matching, canonicalized `id`) should find
them given the `shell.json` contents above — the same code path that
correctly returns `true` for `bobbynicholas.omaland`. I wasn't able to find
what specifically diverges for these two from reading the QML alone; I
didn't have a way to attach a debugger to the running Quickshell engine to
go further.

## System

```
$ omarchy version
4.0.3-1
$ uname -a
Linux omarchy 7.2.3-arch1-3 #1 SMP PREEMPT_DYNAMIC Sun, 06 Sep 2026 13:01:04 +0000 x86_64 GNU/Linux
Hyprland 0.56.2 (Wayland)
CPU: AMD Ryzen 5 5500U
Machine: IdeaPad 3 15ALC6 (82KU)
Theme: Tokyo Night
```

## Note: `omarchy debug` no longer exists

Unrelated to the above, but noticed while preparing this report: the
skill/doc-referenced diagnostic command

```
omarchy debug --no-sudo --print
```

returns `Unknown Omarchy command` on 4.0.3-1, and `omarchy commands --all`
has no `debug` entry at all. If it was renamed or removed, the contributing
docs (and possibly in-app help) referencing it are stale.