Report #10

Description

user: ash4-test-lenci@25hraf.com Issue Description On the Login page, submitting credentials triggers an authentication error that appears to originate from Supabase auth/session handling, even though Supabase is no longer used by the system. This indicates legacy Supabase client code (e.g., AuthContext, session restore, token refresh, or auth error mapping) is still being initialized and/or intercepting the login flow, resulting in misleading errors and potentially blocking the correct auth provider’s behavior. Expected Behavior Login should use only the current authentication provider. No Supabase client/session logic should initialize, attempt to restore a session, refresh tokens, or influence error messages. If credentials are invalid, the UI should show an error sourced from the active auth backend (with a consistent message and status), without any Supabase-related logs or errors. Acceptance Criteria No Supabase-related console logs/errors during Login page load or login submission (e.g., no AuthContext “No active session found”, no Supabase session/token attempts). Invalid credentials show an error message produced by the current auth backend (correct copy + correct error code mapping). Valid credentials authenticate successfully without any Supabase calls. Network tab shows zero requests to Supabase endpoints (e.g., /auth/v1/*, rest/v1/*, realtime/*) during login and session initialization. Removing/disable Supabase does not break routing, landing assets, or session persistence for the current auth system.