Decide whether accounts come back, or close it out

The mock login was removed before publishing (commit ddd0670; files kept in auth-backup-2026-07-28/ in Anna's working copy, and in commit b725da9).

It was never functional: signIn/signUp ignored the password, minted a random UUID and stored a fabricated user in localStorage. Nothing was gated behind it. Publishing it would have meant a real-looking password form collecting passwords and discarding them, for no benefit.

This issue is the decision about whether auth comes back at all.

What auth would actually be for

Today, nothing. Progress tracking (lib/progress.ts) is localStorage-only and never read user, and no content is gated. The one real use case is cross-device progress — which means migrating progress off localStorage into a per-user store. That migration is the work; the login form is the easy part.

If it is revived

The four stubs each carry their intended Supabase call in a // TODO: comment, so the shape was already decided:

• session check → supabase.auth.getSession()
• signIn → supabase.auth.signInWithPassword({ email, password })
• signUp → supabase.auth.signUp({ email, password })
• signOut → supabase.auth.signOut()

Also needed: a Supabase project and env vars (.env* is gitignored — keep keys out of the repo), and a check of whether real auth is compatible with the chosen deploy target (a static export cannot server-render per-user pages).

Done when

Either accounts exist and carry progress across devices, or this is closed with the reasoning that they are not wanted.

Start with lib/progress.ts and the four auth stubs, including their TODO comments, to understand the current localStorage flow and intended Supabase calls. Check the deploy target and the required environment variables before choosing an approach. Done means either authenticated accounts carry progress across devices, or the issue is closed with a documented decision not to add accounts.