Login page drops Supabase auth in favor of local JWT endpoint
Commit `5061e2d` rewrites the login page to POST credentials to `/api/v1/auth/token` on the Python backend instead of calling `supabase.auth.signInWithPassword`. The JWT comes back and gets stored in `localStorage` as `canadian_jwt`.
The change removes the Supabase import entirely from login/page.tsx. The new flow calls fetch("/api/v1/auth/token", { method: "POST", body: JSON.stringify({ email, password }) }), stores data.access_token in localStorage, then navigates to /assistant. The login heading changes from "Log In" to "Log In (LSO Compliant)" and the footer note shifts from the original demo disclaimer to a data sovereignty framing.
The same commit renames redline_parser.py to blackline_parser.py - a zero-content file move, riding along for the Canadian terminology cleanup.
There's an important caveat: signup (signup/page.tsx) still uses Supabase. The PIPEDA compliance commit modifies signup against Supabase as well. So this fork has split auth: the login page points to the self-hosted JWT endpoint, while signup and other parts of the app still depend on Supabase. Two auth paths, and there's no indication they share a user store.
The Python /api/v1/auth/token endpoint itself (from Phase 2) doesn't validate credentials - it issues a token for {"sub": "lawyer_demo"} regardless of what's in the request body. So the "LSO Compliant" branding on the login button is aspirational at this stage.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?