fix: don't bypass double_confirm_changes when mailer_autoconfirm is true

[shkuls]

Problem

Closes #2600

GOTRUE_MAILER_SECURE_EMAIL_CHANGE_ENABLED=true (double_confirm_changes) is silently bypassed when GOTRUE_MAILER_AUTOCONFIRM=true. The email change commits after a single confirmation instead of requiring both the old and new address to confirm.

Related upstream reports:

• verifyOtp fails with otp_expired on the old email address when performing an email_change with double confirmations supabase#32909
• Change email error message supabase#19071

Root cause

In emailChangeVerify, the guard that holds the flow at "one confirmed, waiting for the second" is:

if !config.Mailer.Autoconfirm &&
    config.Mailer.SecureEmailChangeEnabled &&
    user.EmailChangeConfirmStatus == zeroConfirmation &&
    user.GetEmail() != "" {

GOTRUE_MAILER_AUTOCONFIRM controls whether new signups require email confirmation. It is completely unrelated to email change confirmation. ANDing it here means any deployment with mailer_autoconfirm=true — including the default self-hosted and local dev configuration — silently disables double_confirm_changes with no warning or error.

Verified locally

Reproduced the bug against v2.186.0 with GOTRUE_MAILER_AUTOCONFIRM=true and GOTRUE_MAILER_SECURE_EMAIL_CHANGE_ENABLED=true:

• Before fix: email change commits after first verification, second token returns otp_expired
• After fix: email change holds after first verification, commits only after second token is verified