fix: harden returnTo validation against control-character open redirect

[yogeshchoudhary147]

Summary

• isSafeRelativeUrl used a block-list (//, /\) that missed ASCII control characters (TAB 0x09, LF 0x0A, CR 0x0D) — payloads like /%09/evil.com passed validation but browsers strip the control character, turning it into //evil.com (protocol-relative open redirect)
• Replaced the block-list with WHATWG URL parser origin comparison: the parser normalises control characters and backslashes before validation, so the parsed origin is compared against a dummy base to confirm the URL resolves as a same-site path
• Added validation for options.returnTo in both handleLogin and handleCallback, which previously reached their sinks unvetted
• Added regression tests covering the full bypass class from SEC-75663: TAB, LF, CR, and TAB+backslash variants, plus absolute options.returnTo in both handlers

Test plan

• npm test passes (351 tests)
• npm run typecheck passes
• ?returnTo=/%09/evil.com falls back to / instead of redirecting off-site
• ?returnTo=/%0a/evil.com and ?returnTo=/%0d/evil.com fall back to /
• ?returnTo=//evil.com and ?returnTo=/\evil.com continue to be rejected
• Valid relative paths like /dashboard and /settings?tab=1 continue to work