### Problem

There is no way for a plugin to declare that it **replaces** a first-party
service, so two plugins that own the same surface can be enabled at once and both
run.

Bars already have this concept — `omarchy-plugin-enable` refuses to place one as a
widget because "it replaces the bar in use rather than taking a place in one" —
but `kinds: ["service"]` has no equivalent.

Concretely, with a third-party background renderer installed:

```bash
omarchy plugin add https://github.com/example/some-background-plugin --enable
```

`--enable` enables the new plugin but leaves `omarchy.background` enabled. Both
then create a `PanelWindow` per screen in the `omarchy-background` layer and both
register an `IpcHandler` for target `background`, so the desktop ends up with two
stacked background layers:

```
Layer level 0 (background):
  Layer 55ae...: namespace: omarchy-background, pid: 1461557
  Layer 55ae...: namespace: omarchy-background, pid: 1461557
```

with `Handler was registered but will not be used because another handler is
registered for target background` in the log. Which renderer wins is incidental.

Nothing warns the user, and `omarchy plugin add --enable` is the natural command
to reach for.

### Suggestion

Let a manifest declare what it replaces, for example:

```json
{
  "kinds": ["service"],
  "replaces": ["omarchy.background"]
}
```

Then `omarchy-plugin-enable` could disable the named plugin when enabling this
one (and offer to restore it on disable), or at minimum refuse to enable both and
say why — the same shape as the existing bar behaviour.

A lighter alternative: have the shell enable only one service per owned surface
and warn about the rest.

### Workaround

A plugin can detect the clash itself and stand down:

```qml
readonly property bool stockRendererActive:
  pluginRegistry ? pluginRegistry.isEnabled("omarchy.background") : false
```

…then render nothing while that is true. That keeps the desktop correct, but each
plugin has to know the id it competes with and every author has to rediscover the
problem.

### Environment

- omarchy 4.0.2-1
- Related: #9493 proposes selecting a plugin kind by config, which is a similar
  "one plugin owns this surface" question.