improvement(frontend): update login and sign up flow ui to v3 components

[scott-ray-wilson]

Context

This PR updates the login and sign-up flow pages to use v3 components and follow @vmatsiiako's hackathon PR styling #5582

Screenshots

Steps to verify the change

• test login functionality ensuring no regressions and ui updates
• test email and social sign-up flow functionality, ensuring no regressions and ui updates

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
• Tested locally
• Updated docs (if needed)
• Updated CLAUDE.md files (if needed)
• Read the contributing guide

[maidul98]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[greptile-apps]

Greptile Summary

This PR updates the login and sign-up flow pages to use v3 components with a new visual design: a decorative SVG background, a footer with social links, card-based layouts, and a password visibility toggle. The change is largely a UI-only migration with no modifications to API calls, authentication logic, or routing.

Key issues found:

• Unintended form submissions (logic bug): The v3 Button component does not set a default type attribute, unlike the v2 Button which hardcodes type="button". SocialLoginButton (Google, GitHub, GitLab) and OrgLoginButton (SAML, OIDC, LDAP) are rendered inside <form onSubmit={handleLogin}> without an explicit type="button". This means every click on these OAuth/SSO buttons also triggers the email/password form's onSubmit handler, potentially causing spurious error notifications or unexpected API calls. Both components need type="button" added to the inner Button.
• Hardcoded copyright year: AuthPageFooter hard-codes 2026; a dynamic new Date().getFullYear() would be more maintainable.

Confidence Score: 2/5

• Not safe to merge without fixing the missing type="button" on social/org login buttons, which causes unintended form submissions on the login page.
• The UI overhaul is well-executed and visually consistent, but the migration from v2 to v3 Button introduced a functional regression: v2 Button defaults to type="button" while v3 Button does not. Social and org login buttons inside the login form will now also trigger the email/password login handler when clicked, which is a silent behavioral bug affecting all non-email login methods.
• frontend/src/pages/auth/LoginPage/components/SocialLoginButton.tsx and frontend/src/pages/auth/LoginPage/components/OrgLoginButton.tsx need type="button" added to prevent unintended form submissions.

Important Files Changed

Filename	Overview
frontend/src/pages/auth/LoginPage/components/InitialStep/InitialStep.tsx	Login step refactored to use v3 components; social/org login buttons now use v3 Button which lacks a default type="button", causing them to behave as type="submit" inside the form and triggering unintended form submissions.
frontend/src/pages/auth/LoginPage/components/SocialLoginButton.tsx	Migrated from v2 IconButton (type="button" by default) to v3 Button (no default type), causing the button to default to type="submit" inside the login form.
frontend/src/pages/auth/LoginPage/components/OrgLoginButton.tsx	Migrated from v2 Button (type="button" by default) to v3 Button (no default type), causing the button to default to type="submit" inside the login form.
frontend/src/components/auth/AuthPageBackground.tsx	New decorative SVG background component. Purely cosmetic, no logic concerns.
frontend/src/components/auth/AuthPageFooter.tsx	New footer component with social links; copyright year is hardcoded as 2026.
frontend/src/components/auth/InitialSignupStep.tsx	Refactored to v3 components; email signup moved to top of button list; enterprise CTA and T&C links added.
frontend/src/components/auth/UserInfoStep.tsx	Refactored to v3 components; password visibility toggle added; attribution source changed from single-line input to TextArea.
frontend/src/components/navigation/RegionSelect.tsx	Simplified from a modal-based picker to an inline Select dropdown; added compact prop for card header placement.

Comments Outside Diff (1)

1. frontend/src/pages/auth/LoginPage/components/OrgLoginButton.tsx, line 11-24 (link)

   Missing type="button" causes unintended form submission

   Just like SocialLoginButton, the v3 Button here has no default type. Since OrgLoginButton (used for SAML, OIDC, and LDAP) is placed inside <form onSubmit={handleLogin}>, clicking it triggers the form's onSubmit in addition to onClick. This means handleLogin will fire when a user clicks "Continue with SAML/OIDC/LDAP", potentially running email/password login logic unexpectedly.

   Note: this also affects the early-return SAML/OIDC-only branch of InitialStep (config.defaultAuthOrgAuthEnforced), where clicking the only login button would trigger an unintended form submission.

_{Last reviewed commit: ab587bb}

[victorvhs017]

super small nit, fell free to ignore:

should we make the green background go behind the button, too?

[victorvhs017]

Funny behavior if I click send invite without putting any email:

Screenshare.-.2026-03-13.6_30_33.PM.mp4

[victorvhs017]

We updated SAML and OIDC screens, should we update LDAP too?

[victorvhs017]

Also, when I click LDAP the email field is validated:

Screenshare.-.2026-03-13.6_35_23.PM.mp4

[victorvhs017]

Why we don't have the footer in the login?