Mail App: Correct Login Redirect Return URL Behind Reverse Proxy

Fixed a bug in the Mail application where logged-out users sent to the sign-in page were given an incorrect return address (localhost:3000) instead of the real site address. After signing in, the return-to link now points back to the correct deployed Mail URL. This change has reached the QA environment.

When the Mail app runs behind Docker and a reverse proxy (as it does in deployed environments), the server sees the internal container address rather than the public one. The login redirect was built from that raw request URL, so the returnTo parameter handed to the SSO sign-in page contained localhost:3000. Users could be returned to an invalid address after authenticating instead of back to the page they were trying to reach.

Users who hit a protected Mail page while logged out are now redirected to SSO with a correct, environment-appropriate return address and land back on the intended page after signing in. This removes a broken post-login redirect in proxied/Docker deployments (QA and beyond) and makes the login flow reliable.

• Single file changed: apps/mail/src/middleware.ts (9 additions, 2 deletions).
• Added a MAIL_APP_URL constant resolved via the existing getAppUrl("mail", process.env.NEXT_PUBLIC_MAIL_APP_URL) helper, mirroring how AUTH_APP_URL is already resolved (also supports Vercel preview deployments).
• In the no-session redirect branch, replaced encodeURIComponent(request.url) with a return URL built from MAIL_APP_URL plus request.nextUrl.pathname + request.nextUrl.search, then URL-encoded.
• The constructed returnTo is appended to the auth app login URL exactly as before; no change to the auth app, cookie handling, or cache headers.

Low risk: scoped to one middleware code path (the logged-out redirect) in a single file, with no API or data changes. Main dependency is correct configuration of NEXT_PUBLIC_MAIL_APP_URL per environment; if that variable is unset or wrong, the return URL would be wrong (the getAppUrl helper provides a fallback). The original behavior is otherwise unchanged. Mitigation: verify the env var is set in each deployed environment.

• In QA, visit a protected Mail URL (e.g. the QA Mail domain) while logged out and confirm the redirect goes to SSO.
• Inspect the SSO login URL's returnTo parameter: it must reflect the real QA Mail domain (not localhost:3000) and preserve the original path and query string.
• Complete sign-in and confirm you land back on the originally requested page.
• Sanity-check that already-authenticated users and public/unprotected paths are unaffected.