auth login: show when credentials are being saved, and explain expired codes

[Ben2W]

Summary

Two pscale auth login messages make a working login look stuck or broken.

1. "Waiting for confirmation..." stays up after access is approved

After the browser approves the device, login saves the token to the system keyring. On Linux that can block on an unlock prompt, such as GNOME Keyring's password dialog, which may open on another screen or behind other windows. The spinner keeps saying "Waiting for confirmation..." the whole time, so the user keeps looking at the browser step even though it already succeeded. This is the situation in #1132, which was closed when the reporter found the keyring popup, but the CLI output was never changed.

On a machine with a locked login keyring, the keyring's prompter process starts one poll interval after auth login starts. The pscale process then has no connection open to the auth server, and it stays on "Waiting for confirmation..." well past the code's 5-minute expiry.

Once the token arrives, the spinner now changes to:

Access approved. Saving credentials to your system keyring; if it asks to be unlocked, enter your keyring password...

It uses the existing ProgressHandle.Update, the same way metrics report and the D1 import progress do. JSON mode is unchanged.

2. An expired code is reported as a server failure

The token endpoint currently returns the same error_description for every device-flow error, including authorization_pending and expired_token:

{"error":"expired_token","error_description":"The authorization server encountered an unexpected condition which prevented it from fulfilling the request."}

ErrorResponse.Error() returns only the description, so when a confirmation code expires before it's approved, login reports what reads like a server crash. The terminal device-flow errors from RFC 8628 §3.5 are now described from their error codes:

• expired_token: "the confirmation code expired before it was approved; run 'pscale auth login' again"
• access_denied: "the login request was denied in the browser"

Other errors still use the server's description. The server's generic error_description for these codes may be worth fixing too.

Testing

• go build ./..., go vet, staticcheck on the changed packages, and go test ./... all pass.
• New TestGetAccessTokenForDeviceTerminalErrors covers expired_token and access_denied arriving with the generic description.
• Reproduced (1) in a pseudo-terminal against a local fake auth server that approves on the third poll. D-Bus was pointed at a nonexistent socket so the CLI used its token-file fallback, and that file was a FIFO, so the save blocks the same way a keyring unlock prompt does. While the save was blocked:
  • before: ⠼ Waiting for confirmation...
  • after: ⠴ Access approved. Saving credentials to your system keyring; if it asks to be unlocked, enter your keyring password...
  • Both print Successfully logged in. once the save completes.

🤖 Generated with Claude Code