## Summary

When `omarchy.lock` is cloned (`omarchy plugin clone omarchy.lock`) and the clone is enabled, the built-in `omarchy.lock` is still instantiated briefly every time the shell starts or reloads its plugins. For a moment two `WlSessionLock` services run in the same Quickshell process. If a lock is active or being recovered at that moment, Quickshell aborts and Hyprland shows "Oopsie daisy… your lock screen app died".

## What happened

`shell.json` has the expected state after cloning:

```json
"plugins": [{ "id": "mei.lock" }],
"disabledPlugins": ["omarchy.lock"],
"cloneSourceRestores": ["mei.lock"]
```

On every shell (re)start, both IPC handlers register. The duplicate-handler warning shows up for both files:

```
WARN scene: QML IpcHandler at file:///usr/share/omarchy/shell/plugins/lock/Service.qml[510:3]: Handler was registered but will not be used because another handler is registered for target lock
WARN scene: QML IpcHandler at file:///home/<user>/.config/omarchy/plugins/mei.lock/Service.qml[510:3]: Handler was registered but will not be used because another handler is registered for target lock
```

Both instances then run stranded-lock recovery, 50 ms apart:

```
11:13:25.781Z lock-stranded: recovering
11:13:25.781Z lock-requested
11:13:25.781Z lock-pending: screen-stabilizing
11:13:25.831Z lock-stranded: recovering
11:13:25.831Z lock-requested
11:13:25.831Z lock-pending: screen-stabilizing
```

Another occurrence ended in a crash:

```
22:41:02 omarchy lock lock-stranded: recovering
22:41:02 omarchy lock lock-requested
22:41:02 omarchy lock lock-pending: screen-stabilizing
22:42:12 FATAL: Tried to show lockscreen surfaces without active lock
22:42:12 ERROR: Quickshell has crashed
```

The user was left at Hyprland's "lock screen app died" screen and had to end the session.

## Likely cause

`PluginRegistry.isEnabled()` (`shell/services/PluginRegistry.qml` ~L123–139) treats first-party plugins as enabled unless `disabledPlugins` lists them. In `shell.qml`'s `Component.onCompleted` (~L145–156), `pluginRegistry.rescan()` and `shell._syncServices()` can run before `shellConfig` is populated. At that point `shellConfigProvider()` returns null, `isDisabled()` returns false, and `omarchy.lock` is instantiated together with the clone. Later, `onShellConfigChanged` → `pluginsChanged` → `_syncServices()` destroys it, which can happen in the middle of a session lock.

A `keepLoaded` service holding a `WlSessionLock` is the worst case, but any disabled first-party service probably has the same startup race.

Possible fixes:
- Don't sync services until the user `shell.json` has been read (or treat "config not loaded yet" as "not enabled").
- Skip a first-party plugin when an enabled clone exists (`clonedFrom` matches), as `resolveEnabledId` already does for routing.

## Steps to reproduce

1. `omarchy plugin clone omarchy.lock` and enable the clone (source goes into `disabledPlugins`).
2. `omarchy restart shell`. Both `lock/Service.qml` IPC handlers register (see the warnings above).
3. Lock the screen, then let the shell restart or reload while locked (e.g. suspend/resume where `omarchy-sleep-lock` triggers recovery). Stranded recovery runs twice, and the lock sometimes crashes with `Tried to show lockscreen surfaces without active lock`.

Workaround: `omarchy plugin disable <clone>` to go back to the built-in lock. After that, only one handler registers and the problem is gone.

## System

- Omarchy 4.0.0-1
- Hyprland 0.56.2-1
- quickshell-git 0.3.0.r20.g28771c7-2
- AMD Ryzen 9 7940HS (Radeon 780M) + NVIDIA RTX 4060 Max-Q (hybrid)
- Kernel 7.1.8-arch1-3