## Summary

On (almost) every resume from sleep, the Omarchy QML lock screen (`omarchy-shell`, built on `quickshell`) crashes with a fatal Wayland error while trying to draw a lock surface on the transient `"FALLBACK"` pseudo-monitor Hyprland creates during output re-init. This triggers Hyprland's generic "session lock client died" fallback screen (the built-in `hl.clear_crashed_lockscreen()` message). A watchdog then relaunches `omarchy-shell` about a second later, which recovers the stranded lock and shows the normal password prompt — so the machine stays locked/secure throughout, but the crash-and-recover is 100% reproducible on wake.

## Environment

- `omarchy` 4.0.3-1
- `quickshell` 0.3.1-1
- `hyprland` 0.56.2-2
- Arch Linux

## Steps to reproduce

1. Let the machine idle-lock or manually lock (`omarchy-shell lock`), or just suspend/resume the laptop/desktop.
2. Watch the monitor immediately after wake.

## Observed behavior

Hyprland's generic lock-crash fallback screen appears for ~1 second:

> Oopsie daisy, it looks like you locked your screen but the lockscreen app died :(
> ...
> hyprctl --instance 0 eval 'hl.clear_crashed_lockscreen()'
> ...
> killall -9 hyprlock

(Note: this message references `hyprlock`, which isn't even installed on my system — Omarchy's own QML lock screen is the actual session-lock client here, so the message is a bit misleading in this context, but that's a Hyprland-side generic message, not something Omarchy controls.)

It then self-recovers to the normal lock/password screen a moment later.

## Root cause (from journalctl)

```
omarchy-shell[251864]:  DEBUG: Not creating lock surface for screen QScreen(0x7f1fad4e3180, name="") as it is not backed by a valid wayland output.
   ... (repeated for several QScreen instances) ...
omarchy-shell[251864]:   INFO qt.qpa.wayland: There are no outputs - creating placeholder screen
omarchy-shell[251864]:   WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
uwsm_hyprland.desktop[1067]: error in client communication (pid 251864)
omarchy-shell[251864]:   WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
omarchy-shell[251864]:   WARN: The Wayland connection experienced a fatal error: Invalid argument
omarchy-shell[257062]: Omarchy shell exited with status 255; relaunching.
omarchy-shell[257064]:   INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
omarchy-shell[257064]:  DEBUG qml: omarchy lock 2026-09-10T16:09:02.755Z lock-stranded: recovering
omarchy-shell[257064]:  DEBUG qml: omarchy lock 2026-09-10T16:09:02.756Z lock-requested
omarchy-shell[257064]:  DEBUG qml: omarchy lock 2026-09-10T16:09:02.756Z lock-pending: screen-stabilizing
```

Sequence:
1. On resume, Hyprland briefly reports a synthetic `"FALLBACK"` monitor as outputs come back online.
2. `omarchy-shell`'s QML/Wayland layer tries to create lock surfaces against screens not yet backed by a valid Wayland output, repeatedly failing (`Not creating lock surface for screen ... not backed by a valid wayland output`), then falls back to a placeholder screen.
3. Shortly after, the removal of the `"FALLBACK"` monitor isn't handled cleanly by `quickshell.hyprland.ipc`, and the Wayland connection dies fatally (`Invalid argument`), killing `omarchy-shell` (exit 255).
4. A supervisor relaunches `omarchy-shell` (`Omarchy shell exited with status 255; relaunching.`), which detects the orphaned lock (`lock-stranded: recovering`) and re-establishes it correctly.

This has happened on essentially every wake-from-sleep in my logs over the past few days (checked timestamps: 10:09, 11:23, 12:03, 13:02, etc. — same pattern every time).

## Expected behavior

`omarchy-shell` should handle the transient `FALLBACK` monitor during output re-negotiation on resume without crashing the whole process — e.g. defer lock-surface creation until a real output is available, rather than hitting a fatal Wayland error.

## Screenshot

Attached: the Hyprland fallback screen shown mid-crash.