[chris-010]

One failed fingerprint press at the login screen ends the PAM conversation, and
the fingerprint reader stays unusable until the greeter restarts.

This is a different cause from the two open reports that share the symptom, and
neither is fixed by this change:

• [BUG] Lock screen doesn't allow entering password while it is asking for fingerprint #173 (and Fingerprint authentication fails/hangs on resume from suspend due to fprintd restart race condition #470, closed as its duplicate) is the lock screen after suspend —
  locker.rs, a conversation that went stale while the machine slept.
• cosmic-greeter crashes on boot/wake due to fprintd device claim race condition #507 is a startup ordering race — the greeter begins a PAM conversation
  before fprintd is ready, and greetd crashes. It needs no user interaction.
• This needs exactly one failed press and no suspend: the greeter cancels its
  own session because it treats a PAM message about the attempt as fatal.

Cause

AuthMessageType::Error is PAM_ERROR_MSG — a message about the current
attempt, not the end of the conversation. pam_fprintd sends
Failed to match fingerprint that way and keeps going until max-tries is
reached. src/greeter/ipc.rs turned it into Message::Error, which cancels the
greetd session.

The session created right afterwards then loses the race for the fingerprint
reader: its PAM worker calls fprintd's Claim 14 ms after the cancel, while the
previous worker still holds it, so the claim is denied and no fingerprint prompt
ever appears again.

Delaying the new session does not help. The previous worker keeps the claim until
it next tries to talk to the greeter, which can be arbitrarily far away — in one
measurement 7.76 s, and it was the correct finger that finally woke it, which
the dead worker then consumed instead of logging in.

Change

The message is routed to its own Message::AuthError, which shows the text and
acknowledges it with PostAuthMessageResponse { response: None } — the same
handling the Info arm already uses, as the greetd protocol requires for a
non-interactive message. Message::Error and the Response::Error path are
unchanged, so a genuinely failed authentication still cancels the session.

Testing

ThinkPad T490, Synaptics 06cb:00bd, pam_fprintd max-tries=5, Pop!_OS 24.04.
Four greeter sessions: three after logging out, one after a cold boot.

• failed press, then correct press (logout path) → the prompt comes back by
  itself after 111 ms and the correct finger logs in. Before the change: reader
  dead, password only.
• five failed presses, once after logout and once after a cold boot →
  max-tries is exhausted on a single device claim, PAM falls through to
  pam_unix, and the password field appears on its own.
• wrong password → still cancels, via Response::Error; the new session gets the
  claim and fingerprint login works again.
• successful press on the first try → unchanged.

In all four sessions a single greetd worker served the whole login, and there was
no Device was already claimed in the journal.

Measured on one sensor model; I cannot speak for other readers.

• I have disclosed use of any AI generated code in my commit messages.
• I understand these changes in full and will be able to respond to review comments.
• My change is accurately described in the commit message.
• My contribution is tested and working as described.
• I have read the Developer Certificate of Origin and certify my contribution under its conditions.