## Environment

- Omarchy 4.0.1-1, fresh install, default autologin (`/etc/sddm.conf.d/autologin.conf`), Hyprland session on a laptop
- Reproduced twice, deterministically, on separate cold boots

## What happens

On a cold boot with autologin, the session starts and the lock engages at startup. The lock's password field accepts typing, but submitting input (any text, including a real password or the string `yes`) is **silently dropped**: no PAM conversation starts, there is no failure flash, and the field just resets. Waiting 10+ seconds after the lock appears before submitting does not help.

Once the session is up, locking manually works perfectly: the same dialog, the same `omarchy-lock-password` PAM service, authentication succeeds normally.

## Evidence

1. **No PAM conversation runs at the cold lock.** I have face authentication wired into `omarchy-lock-password` (a `pam_irlume.so` line, plus the same in sudo/polkit-1). At the cold-boot lock, `yes` + Enter never reaches PAM: the auth daemon's journal (which logs every attempt on every other surface) shows zero requests during the cold-lock window. Fingerprint also does not engage there. So input is dropped before `passwordPam.start()` could matter, or the start itself never happens.
2. **The lock plugin logs nothing at cold start.** `Service.qml` logs `omarchy lock <ts> <event>` on `lock-requested` etc. via `console.log`. The shell's journal for the whole boot contains zero `omarchy lock` events, even though the lock surface was visibly up and accepting keystrokes. That suggests the cold-start surface never went through `beginLock()` (stranded-lock recovery path), and `lockRequested` is therefore false while the UI is visible.
3. **The silent-drop path exists in the code**: `submitPassword()` opens with `if (!lockRequested || authenticatingPassword || password.length === 0) return` and `LockView` binds `inputEnabled: root.lockRequested`. A visible, typeable lock that drops submissions with no feedback is the observed behavior of exactly that guard.

## Why it matters

A visible lock screen that ignores submitted authentication, with no error feedback, is security-relevant on its own (users cannot tell dropped input from a wrong password) and it breaks every PAM-integrated unlock helper (biometric agents like irlume or pam_fprintd lanes) precisely at the moment the machine is most likely to be locked: right after boot.

## Reproduction

1. Install with autologin (the default)
2. Reboot
3. At the startup lock, type anything and press Enter
4. Observe: no failure message, no PAM activity (verifiable with any PAM-logging module wired into `omarchy-lock-password`), field resets

Contrast: lock manually from the running session; the same input path works.

Happy to provide the daemon-side journal excerpts or test a patch if useful.