feat(frontend): landing page CTA goes straight to login/register (#386)

[parthrohit22]

Summary

Product-direction clarification: PARTHA stays self-hosted only for the foreseeable future, with no hosted service planned. The landing page's guest "Analyze a Repository" CTA currently opens the waitlist modal instead of linking to account creation. For a self-hosted instance, there's no reason to gate a fresh guest behind a waitlist prompt in the UI — they should be able to go straight to Login or Create Account.

Linked issue

Closes #386

Scope

• Issue or RFC this advances: feat(frontend): landing page CTA should go straight to login/register, not the waitlist #386.
• Why this is in scope: a direct product-direction clarification from the owner, following the feat(marketing): free static marketing site with a scripted product simulation #382 marketing-site self-host-only pivot.
• Accepted evidence it is real: full vitest suite green (439/439), production build clean, real in-browser click-through against actual running dev servers (backend + frontend) confirming the new CTA behavior in both light and dark mode.

What changed

apps/frontend/src/app/pages/LandingPage.tsx: the unauthenticated analysisCta (all three "Analyze a Repository" hotspot positions — nav, hero, and footer share the same handler) now links directly to /register instead of opening WaitlistModal. This matches the authenticated case's existing direct /upload link and the "Log In" nav hotspot's existing direct /login link — both of those were already unaffected by any waitlist gate. Removed the WaitlistModal import and waitlistOpen state entirely.

Registration itself is unchanged: it still enforces the admin-managed email allowlist (#374/#375) or the local development bypass (#384) exactly as before — a not-yet-approved email still gets the same "hasn't been approved... join the waitlist and we'll be in touch" rejection message on submission, which is unrelated to and untouched by this change. This PR only changes what the landing page's CTA points at, not what completing registration requires.

Deliberately not touched, per the issue's own scope: the backend /waitlist route, WaitlistEntry model/migration, scripts/list_waitlist.py/scripts/approve_email.py, and the frontend's features/waitlist module (WaitlistModal, useWaitlistForm, API client). All of it is now unreferenced by the landing page but still present and still covered by its own tests. Whether that infrastructure should be removed entirely is a separate, larger, cross-cutting question — flagged in PR #383's description, not decided yet, and explicitly out of scope here.

Updated router.test.tsx's one affected assertion to match the new link-based CTA instead of the old waitlist-button one.

Acceptance criteria completed

• Unauthenticated "Analyze a Repository" hotspots on the landing page link directly to /register instead of opening WaitlistModal.
• "Log In" nav hotspot continues to link directly to /login (unchanged, verified).
• No waitlist modal or "waitlist" copy anywhere reachable from the landing page's guest CTAs (checked with a full-page text search after the change).
• apps/frontend's own WaitlistModal/useWaitlistForm/backend /waitlist route left in place, untouched.
• Existing test coverage (router.test.tsx) updated to match the new behavior; full suite green.

Testing performed

cd apps/frontend
npx tsc -b --noEmit   → clean
npm run lint          → eslint ., clean
npx vitest run        → 74 files, 439 tests, all passing
npm run build         → tsc -b && vite build, clean

Manual, in-browser (not assumed from code), against real running dev servers (npm run dev:backend + the frontend dev server), in both light and dark mode:

• Landing page as a fresh, unauthenticated guest: clicked "Analyze a Repository" → landed directly on /register ("Create your PARTHA account"), no waitlist modal at any point.
• Clicked "Log In" → landed directly on /login ("Sign in to PARTHA").
• Confirmed via DOM query that all three "Analyze a Repository" hotspot positions carry the same "Create an account" accessible label (all wired to the same handler).
• Full-page text search for "waitlist" on the rendered landing page: zero matches.
• Repeated the "Analyze a Repository" click in dark mode: same direct /register navigation, no waitlist modal.

Screenshots

Verified visually in-browser in both light and dark mode (landing page, register page, login page) — not attached here, but real screenshots were taken and inspected, not skipped.

Security and data considerations

No security-relevant change: this only changes a link target in the UI. The allowlist enforcement this UI change routes users toward is entirely unaffected — same backend validation, same rejection message, same admin-approval flow.

Dependencies and blocked work

None. The flagged question about removing the backend /waitlist route and the frontend features/waitlist module entirely (now unreferenced from any page) remains open, tracked in PR #383's description — not a blocker for this PR, and not undertaken here.

Scope changes or remaining work

None for this PR's scope.

Contributor checklist

• This PR targets dev
• I claimed the issue and had it assigned or acknowledged before starting substantial work
• The branch was created from an up-to-date upstream/dev
• The branch is rebased on the latest upstream/dev
• This PR addresses one clearly scoped issue
• This PR is in scope: it advances a tracked issue (Scope section filled)
• Every acceptance criterion I claim as complete is actually complete
• Relevant tests pass (typecheck/lint/test/build, per Testing performed)
• Documentation is updated for any user-visible change (none needed — no README/docs described the old waitlist CTA)
• No secrets, credentials, local env files, or generated artifacts are included
• No unrelated files were changed (only LandingPage.tsx and its one affected test assertion)
• Closing syntax (Closes) is used only because the issue is fully resolved
• Dependencies and follow-up work are linked (the backend/frontend waitlist-infrastructure question is flagged in feat(marketing): free static marketing site reusing the real landing page (#382) #383, not a blocker here)

[parthrohit22]

Re-verified after a report that `#how-it-works` still opened the waitlist modal in the real app.

Root cause: that report was against `dev`, not this branch. `dev` still has the pre-fix `LandingPage.tsx` (this PR is unmerged), where `analysisCta` still opens `WaitlistModal` for guests — clicking the "Analyze a Repository" hotspot sitting right next to "See how it works" in the hero would show exactly that.

Did a full sweep of this branch anyway, not just a re-check of the 3 known spots:

• `grep` for every `WaitlistModal`/`useWaitlistForm`/waitlist-open-state reference in `apps/frontend/src` outside the module's own definition/tests: none.
• Full DOM inventory via JS (`document.querySelectorAll('a, button')` inside ``): all 35 interactive elements on the landing page, cross-checked against source. Zero waitlist references anywhere — confirms there's no 4th/5th trigger point, only the 3 `analysisCta` call sites this PR already fixed (nav, hero, near-footer), all now linking straight to `/register`.
• Real click-through of every one of those 35 elements (nav links, both CTA buttons, all 6 FAQ buttons, all 7 footer "coming soon" buttons, external links, theme switcher), in both light and dark mode, via real mouse clicks in an actual browser against real running dev servers. Zero paths reach a waitlist modal.

No code changes needed on this branch — it was already correct on this exact point. Flagging for whoever merges this: until it lands, dev and any local checkout of dev will keep showing the old waitlist-gated behavior.