Unprotected .vercel.app project alias serves the full production build, and is the PKCE-mismatch mechanism

Measured live by coder-terra-cc on project prj_HTTOJEAeVtjuJ3BJMYvyck2xmYaq: terra-enamel-pensanta-com.vercel.app/login returns HTTP 200 with no auth and no redirect - identical production build to the canonical origin (same deploymentId dpl_5haQSeQk3KRq1naph9Q64x57VaCn, /api/health version 0.16.5, dbOk true, real login page with Google button). Deployment protection is ssoProtection with deploymentType all_except_custom_domains, which gates the two deployment-specific aliases (both 302 to vercel.com/sso-api) but does NOT gate the project-level .vercel.app alias. Two consequences. (1) SECURITY: a second unprotected front door to production. (2) FUNCTIONAL, and this is TERRA-18 mechanism: createBrowserClient writes the PKCE verifier scoped to whatever origin served /login, while login-card.tsx pins redirectTo to the hardcoded PRODUCTION_ORIGIN (site-config.ts:6), so entry via the .vercel.app host guarantees the callback lands on the canonical host and cannot read the verifier - producing the exact recorded exchangeFailed string. The redirectTo pin is CORRECT and must stay; the defect is the second front door, not the pin. CAUTION ON THE FIX: do NOT set ssoProtection to cover all deployments - that would gate the custom domain terra-enamel.pensanta.com and lock out every real user. Removing or repointing the project-level alias does not touch the custom domain and is the reversible direction.