Hit pages we didn't get the first pass: rss, gear, show-coverage,
articles/[slug], contributor, manufacturers, login, client-login, terms,
dashboard/show-calendar, and team-page derive helpers (domain + comment).
Logs success payload (sans secrets — just success/migrated/legacy/uid/
email/hasToken booleans) and the post-login document.cookie state so
DevTools can show whether the auth cookie actually landed in the
browser before the /contributor redirect runs.
The previous attempt at hydrating the Supabase browser client via
supabase.auth.setSession() was racing against the server-set cookie.
The server cookie was written with Path=/; SameSite=Lax (no Secure
flag — Next.js cookies().set defaults), but the browser supabase
client's setAll handler writes cookies with Secure; SameSite=None.
The two writes for the same cookie name produced inconsistent state.
Drop setSession + router.push entirely. Instead, do a hard
window.location.href = '/contributor' redirect after a successful
POST. The server renders /contributor with the freshly-set auth
cookie; the browser supabase client boots up reading it from
document.cookie on page load. No client-side hydration race.
The wp-login API sets the auth cookie via NextResponse, but a
client-side router.push() doesn't always pick up the new cookie before
the destination page's AuthContext snapshots auth state — leading to a
brief 'logged out' flash on /contributor right after a successful
login.
Fix: after a successful POST to /api/auth/wp-login, call
supabase.auth.setSession({ access_token, refresh_token }) using the
session payload returned by the API. That hydrates the Supabase
browser client (and therefore AuthContext) immediately, so the next
render is authenticated. router.refresh() is also called to invalidate
the Next.js Router Cache for any stale RSC payloads.
Also adds console.error on both the !res.ok branch and the catch block
so login failures are inspectable in DevTools.
