OAuth redirectTo pinned to validated canonical origin (was window.location.origin)

Fleet finding relayed via pm-pluto-cc from pmmaster-evolutiva-cc; mars had the same anti-pattern. Pluto CONFIRMED affected: src/app/login/login-client.tsx built the OAuth return URL as ${window.location.origin}/auth/callback while src/lib/site-config.ts already exported the fail-closed resolveSiteOrigin(). Fix: redirectTo now uses resolveSiteOrigin(). Regression guard added at src/app/login/oauth-redirect-origin.test.ts (4 tests, mutation-checked: reverting the call site fails 2 of 4). Not the TERRA-20 class (that was a domain-redirect config gap). This is the call site itself reading an unvalidated runtime origin. Open follow-up, NOT closed by this commit: the Supabase Redirect-URL allowlist is the server-side backstop and was NOT inspected. A wildcard entry there (e.g. a *.vercel.app preview pattern) is what decides whether this was exploitable or hygiene, and nothing in the repo shows it. Someone with Supabase auth-config access should read it. Known consequence, deliberate: resolveSiteOrigin() is fail-closed to PRODUCTION_ORIGIN, so a local-dev OAuth login now returns to prod instead of localhost. Accepted rather than adding a dev carve-out, because a dev-mode escape hatch in a security helper is exactly the fail-open shape site-config.ts was written to remove.