## Summary

After the lock screen blanks the display, waking it does not restore focus to
the password field. Keystrokes go nowhere. The only way to recover is to click
with a mouse or tap the touchpad, which defeats keyboard-only operation.

## System details

- Omarchy: 4.0.1-1
- Hyprland: 0.56.2 (commit efb5099)
- quickshell: 0.3.1-1
- CPU: Intel Core i9-9980HK
- GPU: Intel UHD Graphics 630 + NVIDIA RTX 2080 Mobile
- Single internal display (laptop)

## Steps to reproduce

1. Leave the machine idle until it locks (`idle.lock` in `shell.json`), or run
   `omarchy system lock`.
2. Wait ~5s more for `idleBlankTimer` to blank the display.
3. Wake the machine by pressing a key.
4. Type your password.

**Expected:** characters appear in the password field.

**Actual:** nothing happens. The field is visibly unfocused. Only a mouse click
or touchpad tap restores focus, after which typing works normally.

## Root cause

In `shell/plugins/lock/LockView.qml`, focus is asserted in exactly two places:

```qml
onInputEnabledChanged: {
  if (inputEnabled) Qt.callLater(forcePasswordFocus)
}
Component.onCompleted: {
  syncPasswordText()
  if (inputEnabled) Qt.callLater(forcePasswordFocus)
}
```

`inputEnabled` is bound to `root.lockRequested` (`Service.qml`, in the
`WlSessionLockSurface`). That flips true once when the session locks and then
stays true for the whole lock, so `onInputEnabledChanged` never fires again.
`Component.onCompleted` likewise runs only once.

Meanwhile `idleBlankTimer` calls `runBlank()` ~5s after locking. When the
display comes back, neither trigger re-fires, so nothing re-asserts focus.

The only remaining path is the mouse:

```qml
MouseArea {
  anchors.fill: parent
  hoverEnabled: true
  onClicked: { root.wakeRequested(); root.forcePasswordFocus() }
  onPositionChanged: root.wakeRequested()
}
```

Note `onClicked` is the sole caller of `forcePasswordFocus` after lock time.

This is self-reinforcing: `TextInput` has a `Keys.onPressed` handler that calls
`root.wakeRequested()`, but an unfocused `TextInput` never receives key events,
so the keyboard can never recover focus on its own.

## Suggested fix

A self-healing guard in `LockView.qml` re-asserts focus whenever the field has
lost it while input is live:

```qml
Timer {
  interval: 250
  repeat: true
  running: root.inputEnabled && root.visible
  onTriggered: if (!passwordInput.activeFocus) root.forcePasswordFocus()
}
```

This touches no lock/unlock or PAM logic; worst case it re-focuses an
already-focused field. Applied locally on 4.0.1-1 via a cloned plugin; the
shell loads it without QML errors and password PAM auth is unaffected.

An event-driven alternative would be to call `lockView.forcePasswordFocus()`
from `runWake()` in `Service.qml`, but the timer also covers wake paths that
do not route through `runWake()` (e.g. compositor-driven DPMS restore).

## Workaround

Clone the plugin and apply the patch above:

```bash
omarchy plugin clone omarchy.lock
# then add the Timer to ~/.config/omarchy/plugins/<user>.lock/LockView.qml
omarchy restart shell
```