Frontend: login/signup block any email containing "@agpt.co" (agpt.com, agpt.co.uk, ...) with a Google SSO message #15290

Summary

The login and signup pages refuse password auth for any email containing the substring @agpt.co and tell the user to "use Google SSO", which also matches unrelated domains such as agpt.com, agpt.co.uk or agpt.company. The server-side guard added for the same rule only matches the exact domain agpt.co, so the two halves disagree.

Affected code

• autogpt_platform/frontend/src/app/(no-navbar)/login/useLoginPage.ts:98 (data.email.includes("@agpt.co"))
• autogpt_platform/frontend/src/app/(no-navbar)/signup/useSignupPage.ts:127 (same check)
• Reference behavior: autogpt_platform/frontend/src/lib/auth/team-email-policy.ts:14-29 (isTeamEmail compares the domain exactly and case-insensitively; its doc comment says "Only the exact domain counts" and "The sign-up page refuses these addresses in the browser; this is the server half").

Trigger / steps to reproduce

1. Open /signup (or /login) and enter an email such as someone@agpt.com, someone@agpt.co.uk or someone@agpt.company, plus a valid password.
2. Submit.
   "someone@agpt.com".includes("@agpt.co") is true (also for .co.uk, .company, .coffee...), so the handler shows "Please use Google SSO ..." and returns before calling the server action.

Expected vs actual

Expected: only addresses whose domain is exactly agpt.co are routed to Google SSO (like isTeamEmail); agpt.com etc. use normal password auth.
Actual: anyone whose domain merely starts with agpt.co cannot sign up or log in with a password from the UI, and gets a message about "an AutoGPT email" that does not apply to them (no workaround on the page since SSO only vouches for real agpt.co Google accounts). In the other direction SOMEONE@AGPT.CO is not caught by the client check (case-sensitive) but is caught by the server.

Severity

Low. Affects only users on look-alike domains, but for them signup/login is blocked entirely.

How confirmed

Read both handlers and team-email-policy.ts; ran the exact expression in Node: a@agpt.com, a@agpt.co.uk, a@agpt.company -> true; a@previews.agpt.co -> false; A@AGPT.CO -> false. Not verified in a browser.

Fix feasibility

Yes: reuse isTeamEmail from lib/auth/team-email-policy.ts (it has no server-only imports besides APIError type use; if that import is a concern, extract the pure domain check) instead of includes.