feat: resend verification email on sign-in and improve template

[Siumauricio]

Summary

• Add sendOnSignIn: true to emailVerification config — unverified users now receive a new verification email when they attempt to sign in
• Create styled verification email template (matching invoice email design with Dokploy branding)
• Extract sendVerificationEmail helper function to send-verification-email.tsx
• Frontend detects EMAIL_NOT_VERIFIED error and shows a friendly message instead of the raw error

Greptile Summary

This PR adds sendOnSignIn: true to the email verification config so unverified users receive a new verification link on sign-in, introduces a styled React Email verification template matching Dokploy's branding, and shows a friendly frontend message instead of the raw auth error.

• P1 – logger regression: logger.disabled was changed from process.env.NODE_ENV === "production" to false, unconditionally enabling auth logs in production and potentially exposing session/token data in server logs.

Confidence Score: 4/5

Safe to merge after reverting the logger change; all other changes are well-scoped and correct.

One P1 issue remains: the auth logger was unintentionally set to always-on (disabled: false), which enables verbose auth logs in production and should be reverted before merging. All other changes — the email template, the sendVerificationEmail helper, and the frontend error handling — are correct and well-implemented.

packages/server/src/lib/auth.ts — logger configuration regression at line 79.

Comments Outside Diff (1)

1. packages/server/src/lib/auth.ts, line 79 (link)

   Logger always enabled in production

   Setting disabled: false unconditionally re-enables the auth library logger in production, reverting the previous intentional guard (process.env.NODE_ENV === "production"). Better-auth's logger can emit session tokens, user IDs, and request details — having it always on in production creates unnecessary log noise and risks leaking sensitive auth data.

_{Reviews (1): Last reviewed commit: "fix: update logger configuration to disa..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Informational message displayed in error-styled block

setError(msg) feeds into <AlertBlock type="error"> (rendered in red at line 243), while toast.info correctly uses a neutral tone. The message "We've sent a new verification link to your email" is good news, not an error — showing it in a red alert is confusing. Consider introducing separate state (e.g. setInfoMessage) rendered with a neutral AlertBlock type="info", or avoid calling setError here entirely since the toast already communicates the status.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!