## What happened

Resuming from suspend with the session already locked sometimes brings up the
Omarchy lock screen with its password field already populated — a short run of
characters I did not type. Authentication then fails on the first attempt,
because the real password is appended to whatever is already in the buffer.

## What I expected

The password field to be empty on every wake, as it is on a fresh lock.

## Steps to reproduce

1. Lock the session (`omarchy system lock`, or let it idle-lock).
2. Suspend, and leave the machine suspended for a while.
3. Resume and look at the password field before typing.

It is intermittent, not every wake.

## The Omarchy part

`resetAuthenticationState()` in `shell/plugins/lock/Service.qml:116` clears
`enteredPassword`. It is called from exactly three places:

- `beginLock()` (:134)
- `finishUnlock()` (:155)
- the unlock branch of `onLockStateChanged` (:259)

All three are lock/unlock transitions. Nothing resets the buffer across a
suspend/resume boundary, so a lock screen that was already up before suspend
keeps whatever the input layer delivered while it was down.

The plugin has no `PrepareForSleep` handler, but it is not unaware of resume
elsewhere — `idleBlankTimer` (:418) explicitly compensates for a countdown
frozen by suspend by checking wall-clock drift:

```qml
// A countdown frozen by suspend fires right after resume, which would
// blank the freshly woken unlock screen under the user. Wall-clock time
// exposes the gap: take a fresh run-up instead of blanking.
if (Date.now() - armedAt > interval + 2000) {
```

The same resume boundary that gets special handling for blanking gets none for
authentication state.

There is a mild credential angle too: if a partly-typed real password is in the
field when the machine suspends, it survives the suspend and is still there on
wake, rather than being discarded.

## What I have not established

- **The source of the characters is unconfirmed.** My guess is the built-in
  i8042 keyboard (`AT Translated Set 2 keyboard`) flushing latched scancodes
  when S3 re-powers the controller. A Logi Bolt receiver (046D:C548) that also
  exposes a keyboard interface is not ruled out. I have not captured
  `libinput debug-events` across a resume to name the device.
- **Whether a reset on resume is sufficient.** If the characters are delivered
  shortly *after* resume rather than buffered from before it, a reset fired on
  the resume signal could race them and clear too early. Ordering would need
  checking before settling on a fix.

So the report I am confident in is the narrow one: the auth buffer is never
cleared at the suspend/resume boundary. Whether that fully explains the symptom
is a separate question.

## Relevant local context

This machine is pinned to S3 (`MemorySleepMode=deep`) as a workaround for
#7788. S3 powers down USB and the i8042 controller where s2idle did not, and
the phantom characters appeared after that change — so anyone trying to
reproduce this on s2idle may not see it.

## Workaround

Esc or Ctrl+U clears the field (`LockView.qml:177` `Keys.onPressed`).

## System details

- Omarchy 4.0.0-1, Hyprland 0.56.2-1, quickshell-git 0.3.0.r20.g28771c7-2
- Kernel 7.1.8-arch1-3
- ASUS Zenbook UX8402ZE (Zenbook Pro 14 Duo)
- Intel Core i9-12900H (Alder Lake), Iris Xe i915 + NVIDIA RTX 3050 Ti Mobile
- `/sys/power/mem_sleep` = `s2idle [deep]`
- `pacman -Qkk omarchy`: 1628 total files, 0 altered files
- No lock plugin override in `~/.config/omarchy/`

Related: #7788 (the S3 workaround this appeared downstream of), #6925 (a
different failure in the same auth-state area, closed not-planned).

Filed by Claude Opus 5 via Claude Code.