## Summary

After an idle lock → wake cycle, the shell appears to recreate parts of its panel/component tree without cleanly destroying the previous instances. This is visible as duplicate `IpcHandler` registrations for many built-in panels at once, and — for at least one third-party plugin (Omamail, which owns a real child process rather than just reading shared system state) — it leaks the old instance's backend process as a permanent orphan every time it happens.

This looks related to #11794 (same "no outputs" / "not backed by a valid wayland output" log signature), but that report describes a full session freeze; this one is a quieter case where the session keeps working and the duplication is easy to miss unless a plugin has an externally-visible side effect (like Omamail's does).

## Evidence (`journalctl --user`, times local)

```
17:09:54  omarchy idle  lock-system: lock-timeout
17:09:54  omarchy lock  secure=true
17:12:24  omarchy idle  idle-monitor: idle / idle-cycle-start
17:12:38  omarchy idle  idle-monitor: active / idle-cycle-cancel: activity
17:12:38  omarchy idle  process-start: wake omarchy-system-wake
17:12:39  qt.qpa.wayland: There are no outputs - creating placeholder screen
17:12:40  WARN scene: QML IpcHandler at .../plugins/agents/Panel.qml[327:3]: Handler was registered
          but will not be used because another handler is registered for target omarchy.agents
17:12:40  WARN scene: QML IpcHandler ... target omarchy.bluetooth
17:12:40  WARN scene: QML IpcHandler ... target omarchy.network
17:12:40  WARN scene: QML IpcHandler ... target omarchy.audio
17:12:40  WARN scene: QML IpcHandler ... target omarchy.monitor
17:12:40  WARN scene: QML IpcHandler ... target omarchy.power
17:12:40  WARN scene: QML IpcHandler ... target omarchy.weather
17:12:40  WARN scene: QML IpcHandler ... target omarchy.system-update
17:12:40  WARN scene: QML IpcHandler ... target omarchy.clock
17:12:40  WARN scene: QML IpcHandler ... target omarchy.indicators
17:12:40  WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
17:12:40  DEBUG: Not creating lock surface for screen QScreen(...) as it is not backed by a valid wayland output.
```

The whole `17:12:40`-`17:12:41` block repeats twice in a row, once per (apparently) recreated screen/output — each time re-registering an `IpcHandler` for every one of these targets, and each time losing that registration race ("will not be used because another handler is registered"), which means the **previous** instance is the one that's still alive and serving — the new one is the one left dangling.

## Concrete downstream impact

The Omamail mail plugin (a third-party Omarchy plugin, not part of core) spawns its own long-lived backend process per plugin instance. Each time this duplication happens, the *old* plugin instance's backend process is never told to quit — it becomes a permanent orphan (reparented to `systemd --user`), while a fresh instance and fresh backend process are created. Over a few days of normal idle/lock/wake cycles, 2-3 of these orphaned processes accumulate, each still fully connected to its accounts and holding shared resources (an exclusive file lock, in this case), causing real functional failures in that plugin. Filed separately against that plugin's repo as a defensive mitigation, but the leak itself originates here.

Other built-in panels (bluetooth, network, clock, etc.) don't show a visible symptom from this because they only display state already owned by a system service (D-Bus, NetworkManager, etc.) — a duplicated, losing-race instance of those is just a few harmless orphaned QML objects. A plugin or panel that owns its own external process or exclusive resource will leak it every time this happens.

## Steps to reproduce

1. Let the idle timeout lock the session (or lock manually).
2. Stay away long enough for the display to fully blank/the output to drop (not just the lock surface appearing).
3. Return and unlock/wake.
4. Check `journalctl --user` around the wake timestamp for the `IpcHandler ... will not be used` warnings shown above.
5. If you have a plugin that owns a child process, check whether a second copy of that process now exists (`ps -eo pid,ppid,etime,cmd | grep <plugin binary>`) alongside the original.

## Environment

- Omarchy 4.0.4-1
- Session stayed usable throughout (unlike #11794) — this is the "quiet" variant of that failure family.

## Suggested direction

- Whatever teardown path handles a real lock-screen freeze recovery (per #11794 and siblings) should also run for this quieter case: ensure the previous scene/component tree (and anything it owns, like plugin-spawned processes) is torn down *before* — or instead of racing with — creating the replacement one, rather than leaving the loser of the `IpcHandler` registration race running indefinitely.