### System details

- Omarchy 4.0.0-1 (Quattro), Hyprland 0.56.2 (`configProvider: lua`), quickshell-git 0.3.0.r20
- ASUS ROG Zephyrus G14 (GA403UM), hybrid GPU (NVIDIA RTX 5060 Max-Q + AMD HawkPoint iGPU — internal panel enumerates as `eDP-2`), kernel 7.1.8-arch1-3
- Internal keyboard is a USB device (ASUS ITE 8910); it stayed enumerated the whole time (no xHCI errors in the journal)
- Stock Omarchy lid handling confirmed active: `hyprctl binds` shows the Lua defaults (`switch:on:Lid Switch` → `omarchy-system-lid-close`, `switch:off:Lid Switch` → `omarchy-hyprland-monitor-clamshell`); no custom lid scripts are in play

### What's wrong?

Same symptom as #2991, which was closed with "please open a new issue if this reproduces on Quattro" — it reproduces on Quattro with the native session lock.

Laptop undocked, no external monitor. Close lid → session locks and suspends (s2idle). Open lid → system resumes and the Quickshell lock screen renders normally, but keyboard input never reaches it: the password field stays empty. Closing and reopening the lid again doesn't help. I had to reboot to get back in.

### Journal evidence (affected boot, 2026-08-22)

The lock engaged cleanly before suspend:

```
10:52:44 omarchy-shell: DEBUG qml: omarchy lock ... lock-requested
10:52:44 omarchy-shell: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
10:52:45 omarchy-shell: DEBUG qml: omarchy lock ... secure=true
10:52:45 kernel: PM: suspend entry (s2idle)
```

At each subsequent lid-open (11:52:09 and 11:54:07), resume completed, Xwayland recompiled the keymap a few seconds later — indicating an input/monitor reconfigure happened while the session was locked — and the lock shell logged no input events at all afterwards:

```
11:52:09 systemd-logind: Lid opened.
11:52:10 kernel: PM: suspend exit
11:52:12 uwsm_hyprland.desktop: The XKEYBOARD keymap compiler (xkbcomp) reports:
11:52:12 uwsm_hyprland.desktop: > Warning: Unsupported maximum keycode 709, clipping.
```

### Likely mechanism

This looks like the known Hyprland behavior where the session-lock surface doesn't regain keyboard focus after monitors are reconfigured under an active lock (hyprwm/Hyprland#1548, hyprwm/Hyprland#5072, hyprwm/Hyprland#6785). On lid open, `omarchy-hyprland-monitor-clamshell`'s `enable_internal` path (recover helpers, possible monitor re-apply / `hyprctl reload` / DPMS enable) runs while the session is locked, which fits the keymap-recompile evidence above.

### Possibly related observation

In the same boot, `omarchy-sleep-lock.service` was crash-looping (`Main process exited, code=exited, status=1/FAILURE`, restart counter reached 14). In the current boot it runs fine (`dbus-monitor` falls back to eavesdropping after an AccessDenied on new-style monitoring). The lock itself did engage, so this may be unrelated noise, but I'm including it for completeness.