### What happened

Quickshell (the Omarchy shell) crashes with `SIGABRT` when its QML scene is
live-reloaded (triggered by a local plugin file change) while the screen is
already locked. This is the third such crash in 9 days on this machine — same
failure signature each time.

**Crash log (quickshell's own crash reporter, `~/.cache/quickshell/crashes/<id>/report.txt`):**
```
FATAL: Tried to show lockscreen surfaces without active lock
```
That FATAL line is the last thing logged before `abort()`. The backtrace shows
the abort firing from inside `QDebug::~QDebug()` (Qt's `qFatal` mechanism),
reached through a QML property write on a `QQmlTimer` tick — i.e. one of
Omarchy's own lock-related timers. An earlier crash on this machine (Aug 24)
hit the identical code path with debug symbols intact, resolving to
`WlSessionLock::updateSurfaces`.

### Trigger sequence (from journalctl, timestamps CDT)

1. `13:58:09` — idle timeout locks the screen normally; `secure=true` at `13:58:10`.
2. `13:59:28` — `Local plugin changed, reloading: nostr-signer` — a file change
   under a local plugin directory causes Omarchy to live-reload the **entire**
   shell QML scene (confirmed by every other plugin's `IpcHandler` logging a
   duplicate-registration warning immediately after, at `13:59:29`).
3. The reload destroys and recreates the lock component
   (`plugins/lock/Service.qml`) while the screen is still genuinely locked at
   the Wayland protocol level. The recreated component has no memory of owning
   a lock, so it treats the still-valid lock as "stranded" and calls
   `recoverStrandedLock()` → `beginLock()`, requesting a **second** lock
   (`lock-stranded: recovering` → `lock-requested` at `13:59:29`).
4. That redundant re-lock races quickshell's own async lock-confirmation
   handshake with the compositor. ~69 seconds later (`14:00:38`), quickshell
   tries to show the lock surfaces before that handshake completes, and hits
   its own fatal assertion.

The stranded-lock recovery logic in `Service.qml` (around
`checkStrandedLock()` / `recoverStrandedLock()`) is written for the case where
the quickshell *process* actually restarted and the compositor-side lock
outlived it — the code comment there explicitly says as much. It doesn't
appear to account for a **live QML scene reload within the same still-running
process**, where the lock was never actually orphaned.

### What was expected

A plugin file change reloading the shell while the screen is locked should not
tear down and reacquire the session lock, and should never crash quickshell.

### Steps to reproduce

1. Lock the screen (idle timeout or manual lock).
2. While locked, edit/touch a file under a local plugin in
   `~/.config/omarchy/plugins/<plugin>/` to trigger Omarchy's local-plugin
   live-reload.
3. Wait roughly a minute. Quickshell aborts with `SIGABRT` and the log line
   `FATAL: Tried to show lockscreen surfaces without active lock`.

This reproduced consistently enough to hit twice in 9 days on normal daily use
(Aug 24 and Sep 1) without deliberately trying to trigger it.

### System details

```
$ omarchy version
4.0.2-1
```

`omarchy debug --no-sudo --print` is not available on this install
(`Unknown Omarchy command`), so I can't attach that output.

- Quickshell: 0.3.1 (Arch Linux build), Qt 6.11.2
- GPU: AMD (amdgpu), dual GPU (PCI 03:00.0 + 78:00.0)
- Not caused by the Aug 25 quickshell 0.3.0→0.3.1 upgrade — the identical
  failure reproduced on both versions.
- Not an OOM kill (14GB RAM, 8GB free at diagnosis time).
- No data loss — quickshell auto-restarts in under a second and its own
  recovery logic re-secures the lock immediately after.

### Coredump reference (this machine only, not attached)

```
PID: 3020510, Signal: SIGABRT, Time: 2026-09-01 14:00:38 CDT
Command: quickshell -n -p /usr/share/omarchy/shell
```

---
Filed by Claude Sonnet 5 via Claude Code.