Mail App: Temporary Diagnostic Headers to Investigate QA Authentication Redirect

A temporary, internal-only diagnostic change was deployed to the Mail application's QA environment to investigate why unauthenticated visitors were not being redirected to sign-in on QA. It adds debug information to server responses to help engineering trace the exact cause; it changes no user-facing behavior and is intended to be removed once the root cause is identified.

After a prior change (PR #960), the Mail app's QA environment was observed serving the /inbox page to unauthenticated requests (returning a success response instead of redirecting to single sign-on). The authentication middleware was running but not performing the redirect, and the configured URLs appeared correct. To pinpoint the failing code path, engineering needed visibility into the values the middleware was evaluating at request time.

No functional or visible impact for end users. The change adds X-Debug-* HTTP response headers (not visible in the UI) so engineers can inspect authentication decision inputs on QA. This is purely a temporary troubleshooting aid to help restore correct sign-in enforcement on QA. It is scoped to QA and slated for removal after diagnosis.

• Single file changed: apps/mail/src/middleware.ts (+12 lines, no deletions).
• Adds temporary debug HTTP response headers to the existing NextResponse.next() response, alongside the current Cache-Control: no-store header.
• Exposed values: X-Debug-Skip-Auth (skipAuthMiddleware), X-Debug-Has-Session (hasSession), X-Debug-Is-Public (isPublicPath), X-Debug-Cross-Origin (isCrossOrigin result), X-Debug-Api-Host (hostname parsed from NEXT_PUBLIC_API_URL), and X-Debug-App-Host (request hostname).
• Diagnostic intent: compare the API host vs. app host and inspect session/public-path/cross-origin flags to find why the SSO redirect is not firing.
• No changes to authentication logic, routing, or redirect behavior.

Low functional risk: the redirect/auth logic itself is unchanged, so behavior is the same as before this change. The main concern is information exposure — these headers reveal internal hostnames and middleware flags, so they should not reach Production and must be removed promptly after diagnosis (the PR explicitly notes 'Remove after diagnosis'). Mitigation: keep scoped to QA, verify the headers are stripped before any Production promotion, and track removal as a follow-up.

• Confirm the change is limited to QA and does not get promoted to Production with the debug headers present.
• After QA deploy, run curl -sI https://cortex-mailqa.datagainservices.com/inbox | grep -i x-debug and verify the X-Debug-* headers appear with sensible values.
• Verify normal Mail app behavior (page loads, navigation, existing auth flow) is unchanged versus before the change.
• Track and confirm a follow-up removes these temporary headers once the root cause of the missing redirect is identified.