Feat: implement clerk for authentication and gate /my via server

[akeight]

Closes #138

Summary

• Add a protected Clerk auth flow for /my with server-side route protection.
• Route sign-in and sign-up through a single conditional /auth/[[...auth]] page.
• Update Clerk env/docs and improve embedded auth form contrast and email input padding.

Test plan

• Ran npm --prefix web run lint.
• Ran npm --prefix web run build.
• Smoke-tested /my redirecting to /auth/sign-in and /auth/sign-up rendering locally.

[Jose-Gael-Cruz-Lopez]

Nice work — this is close. I pushed a fix commit on top of the branch (ada66e5) for two things I ran into while testing it locally.

1. /auth/* 500s whenever Clerk isn't configured. layout.tsx only mounts ClerkProvider when the publishable key exists, but the new /auth/[[...auth]] page renders <SignIn>/<SignUp> unconditionally. So with no keys — the documented default, and what you get on a fresh clone — GET /auth/sign-in throws useSession can only be used within the <ClerkProvider /> component and returns a 500. That breaks our "Clerk is optional, the site runs without it" rule. Now /auth/* redirects to /my when Clerk is off, since /my already shows the setup instructions.

2. The /my redirect quietly depends on NEXT_PUBLIC_CLERK_SIGN_IN_URL. auth.protect() resolves its target as signInUrl || <Clerk's hosted account portal>, and signInUrl only comes from the clerkMiddleware options or that env var. Since the PR sets it in .env.example only, any deployment carrying just the two Clerk keys would skip the /auth screens this PR adds and drop users on accounts.dev instead. I pinned signInUrl/signUpUrl in proxy.ts and removed the four NEXT_PUBLIC_CLERK_*_URL vars — they're no longer load-bearing, which also means one less thing to get wrong in the Vercel dashboard.

Smaller stuff in the same commit: unknown /auth segments now 404 instead of serving the sign-in page at every URL (/auth/bogus was returning a 200), the signed-out /my fallback links to /auth/sign-in instead of embedding a second <SignIn> (its path routing is bound to /auth/sign-in and misbehaves mounted on /my), and the duplicated "are both keys set" check is now isClerkConfigured() in lib/env.ts.

CI is green, and lint, build and the 56 tests all pass on the updated branch.

One thing I need from you before I merge: can you run a real sign-in against your Clerk dev instance on the updated branch? Signed-out /my -> /auth/sign-in -> Google/GitHub/email -> back to /my. I don't have Clerk credentials, so I verified the redirect target by reading Clerk's source rather than by actually logging in. And your earlier smoke test would have had NEXT_PUBLIC_CLERK_SIGN_IN_URL sitting in your local .env.local — which is exactly the variable issue 2 is about — so that path hasn't really been proven end to end yet.

Separately, a rollout note for me to sort out: this flips /my from open to gated the moment both keys exist in the environment. The tracker lives in localStorage and isn't tied to an account, so anyone using it anonymously today would hit a login wall and their pipeline wouldn't carry over. I'll confirm whether prod has the keys set before merging.