## What happened

After closing and reopening the laptop lid (suspend → resume), the lock screen's password field stops accepting keyboard input entirely — no characters appear, and the session never unlocks. This has forced a reboot from a TTY every time it's happened (confirmed across three separate occurrences/boots today).

## What I expected

Reopening the lid should resume the session at the lock screen with the password field focused and able to accept input, as it normally does on a fresh lock.

## Steps to reproduce

1. Close the laptop lid (triggers suspend; Omarchy locks the session first via `omarchy-sleep-lock.service` → `omarchy-system-sleep-monitor`).
2. Wait for the system to suspend.
3. Reopen the lid.
4. Try to click into / type into the password field.

Observed with an external monitor sometimes connected and sometimes not (laptop-only and docked), so it doesn't appear to depend on monitor topology, though hybrid graphics may be a factor (see below).

## Evidence

`journalctl --user` across three separate boots today shows the identical pattern — the lock goes secure, and then **no further lock-related event is ever logged again** (no `unlocked`, no `session-locked=false`, no password-failure event) until the session is torn down by a manual reboot:

```
Oct 08 17:05:27 omarchy-shell: DEBUG qml: omarchy lock ... lock-requested
Oct 08 17:05:27 omarchy-shell: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
Oct 08 17:05:27 omarchy-shell: DEBUG qml: omarchy lock ... secure=true
Oct 08 17:05:30 systemd: Started Lock Omarchy before suspend.
Oct 08 17:05:37 systemd: Started Lock Omarchy before suspend.
Oct 08 17:05:39 systemd: Started Lock Omarchy before suspend.
(session later closed manually; no unlock ever logged)
```

Same shape recurs in two other boots from the same session (`17:27:35` and `17:24:57` boots). In all three, `secure=true` is the last `omarchy lock` event ever logged for that boot.

## Suspected cause (from reading the shipped source)

`/usr/share/omarchy/shell/plugins/lock/LockView.qml` only calls `passwordInput.forceActiveFocus()`:
- in `Component.onCompleted`,
- when `inputEnabled` changes, and
- from the background `MouseArea`'s `onClicked`.

None of these fire on resume from suspend when the session was already locked before suspending (`inputEnabled`/`lockRequested` doesn't change, and the `LockView`/`WlSessionLockSurface` isn't recreated). `Service.qml`'s `onScreensChanged` handler calls `requestSessionLock()` (a no-op once already locked) but never re-asserts focus either. If the compositor drops keyboard focus from the `ext-session-lock` surface across suspend/resume (plausible on this hybrid-GPU laptop when outputs are reconfigured), nothing in the lock plugin ever asks for it back, leaving the field permanently inert even to a click, since the click handler's `forceActiveFocus()` is a QML-level focus call that wouldn't help if the Wayland compositor itself isn't routing keyboard events to that surface. (I haven't yet confirmed whether a click into the field restores input — will update this issue with that result.)

## System details

- Omarchy: 4.0.4-1 (stable channel)
- Hyprland: 0.56.2-2
- Quickshell: 0.3.1-1
- Kernel: 7.2.3.arch1-3 (uname: 7.2.5-3-omarchy)
- CPU: Intel Core i7-12700H
- GPU: Intel Iris Xe (integrated) + NVIDIA GeForce RTX 3050 Ti Mobile (hybrid graphics, nvidia driver)
- Monitors: internal laptop panel; external monitor sometimes attached/detached around suspend

(Note: `omarchy debug` is not available as a command on this installed version, so the above was gathered manually via `pacman -Q`, `journalctl`, `lscpu`, `lspci`.)