fix(auth): #154 make auth redirects basePath-aware (email confirm bounced to domain root)

[TortoiseWolfe]

Closes #154

What was happening

On a GitHub Pages project-site deploy (any fork without a CNAME, e.g. RescueDogs at tortoisewolfe.github.io/RescueDogs), a new user who clicked the Supabase confirmation email briefly landed in a signed-in state, then got bounced to the bare domain root where no app exists. Sign-up conversion was fully broken in production.

Two defects stacked:

1. Every hand-built auth URL ignored the basePath. emailRedirectTo was ${window.location.origin}/auth/callback (AuthContext.tsx), and the cross-tab sign-out handler plus signOut() did window.location.href = '/' — the domain root, not the app root. Same class of bug in the OAuth redirectTo, the password-reset redirectTo, and the verify-email / sign-in / error-boundary hard navigations.
2. The resolved basePath never reached client code in production. The deploy workflows intentionally omit NEXT_PUBLIC_BASE_PATH and rely on scripts/detect-project.js → project-detected.json → next.config.ts. That value configured the router, but getProjectConfig() in the browser saw ''. So even a "basePath-aware" URL builder would have produced the wrong URL in the deployed bundle.

The visible bounce was the cross-tab SIGNED_OUT branch: during email confirmation no auth token exists yet, so the token-validity guard classifies the transient SIGNED_OUT as real and the handler hard-navigated to '/' — off the app.

The fix

• src/config/project.config.ts: new getInternalUrl(path) (basePath-prefixed, trailing-slash canonical — trailingSlash: true exports emit route/index.html, and Supabase's redirect allow-list is exact-match, so the slashless form costs a Pages 301 that can break allow-list matching) and getRedirectUrl(path) (runtime origin + basePath, for Supabase redirect params). With an empty basePath both degrade to exactly the old strings.
• next.config.ts: inject the resolved basePath into the client bundle via the env block. This is the load-bearing line for forks — verified by building with a basePath and finding basePath:"/ScriptHammer" inlined in the emitted client chunk.
• Routed all nine call sites through the helpers (AuthContext emailRedirectTo/signOut/cross-tab, OAuthButtons, ForgotPasswordForm, SignInForm, sign-up page, reset-password page, ErrorBoundary).
• Guarded the cross-tab SIGNED_OUT redirect so it never fires on /auth/callback — the callback page owns its own error handling, and a transient SIGNED_OUT there is expected during confirmation.

Tests

• src/config/__tests__/project.config.test.ts: helper behavior with/without basePath, trailing-slash canonicalization, query/hash passthrough, absolute redirect composition.
• tests/unit/auth/use-auth.test.tsx: with NEXT_PUBLIC_BASE_PATH=/RescueDogs — prefixed emailRedirectTo at sign-up, prefixed signOut() redirect, prefixed cross-tab SIGNED_OUT redirect, and no redirect when SIGNED_OUT fires on the callback page (the exact pre-fix bounce).

Suite: unit tests, type-check, lint, gitleaks all green in the container. Existing E2E can't see this class of bug (it builds without a basePath) — follow-up issue coming for a basePath-enabled E2E project.

What this does NOT fix by itself

The Supabase project for each deployed fork needs its dashboard config to match (Site URL inside the app, prefixed callback URLs in the redirect allow-list). For RescueDogs (cmdhajshektesctrappl): Site URL https://tortoisewolfe.github.io/RescueDogs, allow-list additions https://tortoisewolfe.github.io/RescueDogs/auth/callback/, https://tortoisewolfe.github.io/RescueDogs/reset-password/, https://tortoisewolfe.github.io/RescueDogs/**, plus the two localhost equivalents for dev. That project lives in a Supabase account the local tooling has no token for, so it's a dashboard task.

Full-loop verification (real confirmation email → land under /RescueDogs/auth/callback/ → profile) only closes in production after the RescueDogs cherry-pick deploys; not claiming it here.

🤖 Generated with Claude Code