Decrypt stored password before comparing in the 'auth' backend command

[monperrus]

Bug

Basic-auth login (GET /session, POST /jmap) against an IMAP-backed
account fails with 401 {"type":"unauthorized"} on any deployment
that sets JMAP_SECRET_KEY (or configures OpenBao) — i.e. the
documented, recommended production credential-storage setup.

_authenticate() in bin/jmap-proxy.pl sends Basic-auth credentials
to the __accounts__ child's auth command, which does:

my $stored = $udb->selectrow_hashref(
  "SELECT password FROM iserver WHERE username = ?", {}, $email);
return ['auth', undef] unless $stored && $stored->{password} eq $password;

iserver.password is written via JMAP::CredentialStore->encrypt()
during account setup, so it's stored as enc1:base64(...) (or
vault:v1:...), never as plaintext. Comparing that directly against
the plaintext password from the request can never succeed.

The sibling verify_credentials command (a few lines below, same
file) already does this correctly:

require JMAP::CredentialStore;
my $actual = JMAP::CredentialStore->decrypt($stored->{password});
return ['verify_credentials', undef] unless $actual eq $password;

auth was just missing the decrypt step.

Fix

Bring auth in line with verify_credentials: decrypt the stored
value before comparing.

Testing

Verified against a live deployment
(ghcr.io/jmapio/jmap-proxy:latest, JMAP_SECRET_KEY set):

• Before: curl -u 'user@example.com:correct-password' https://.../session → 401 {"type":"unauthorized"}
• After: same request → 200 with a full JMAP Session object, and
  a follow-up Email/query + Email/get call against /jmap
  returned real synced mail from the account.

Related to #63 (a separate bug in the same account-setup path) but
independent — this fixes the login path specifically.