[TC960]

Brings the application portal together in one branch: Elisa's hacker portal update (#8), Satyash's mentor/judge application (#7), and Satyash's mentor/judge/hybrid portal (Mentor/Judge/Mentor+Judge-pages, which had no PR). Merging this closes #7 and #8.

What changed on top of the three branches

• Everyone signs in with Google before applying, mentors and judges included. A mentor/judge application is tied to the account and uses its email, so the portal reads it directly. There's no more matching a typed email to a Google account later.
• Roles come from the live event model. The Supabase project already has events, per-event event_roles, an attendees roster with check-in codes, and triggers that grant roles when an application is accepted. The portal now reads roles from event_roles and sends the current event (EVENT_CODE in src/portal/event.ts) with every application, so accepted people reach the check-in roster. Before this, the sign-in link's ?role= was saved on the profile; now the browser can't set a role or a status.
• After sign-in: anyone with a mentor/judge application goes to /portal. Someone coming from the mentor/judge sign-in pages without one goes to the application form. Everyone else goes to the hacker dashboard.
• One small migration, supabase/migrations/20261021000000_application_portal.sql, replaces the two earlier SQL files. It lets signed-in mentors and judges apply, closes the anonymous route, and stops the browser setting profile role or email. It has already been applied to the live project, after a dry run that was rolled back.
• Portal paths are defined in one place (src/portal/paths.ts), and the deploy workflow writes entry pages for the new routes.
• The tests set jsdom's localStorage again, which Node 25+ hides. 24 staff-portal tests were failing on newer Node because of this.

Before this works on the live site

Add https://datahacks.ds3ucsd.com/** under Supabase → Authentication → URL Configuration → Redirect URLs. The list is empty, so Google sign-in on the real site can't return to /auth/callback.

Testing

• Typecheck, build, and 62/62 tests pass.
• I ran the migration twice against a local Postgres set up like the live project, and once against an empty one. Checks: users can't give themselves a role, accept their own application, submit as someone else, read others' applications, or upload into another user's resume folder. Anonymous inserts are rejected, and accepting or rejecting an application updates the role immediately.
• In the browser, signed out: every portal route redirects to the right sign-in page, the staff portals render in ?preview, and "Create an Account" opens the hacker sign-in.
• Live, against the real project (local dev server): a hacker signs in with Google, applies with a resume, and sees "submitted". A mentor signs in, is sent to the form, applies with their Google email, and sees "Application pending" in the mentor portal. Not yet checked: accepting an application and seeing the role and check-in code appear.

Remaining loose ends are in docs/application-portal-todo.md: a single entrance and one portal for hackers too, DocuSign credentials, real contacts, waiver records in Supabase, and Evan's branch.

🤖 Generated with Claude Code