Auth.js v5 signup and login, cookie bridge to Express backend

The frontend half (20ea4b2) installs next-auth@5, @auth/drizzle-adapter, and bcryptjs. frontend/src/auth.ts configures a Credentials provider that bcrypt-verifies against the local users table via Drizzle. A new /api/signup route creates user and user_profiles rows in a single transaction. AuthContext.tsx is rewritten on top of useSession().

Two tightening commits follow: the signup form's minimum password length was 6 in the UI but 8 on the server - that gets aligned (1ab63b7). Then a follow-up (2d8ee13) adds a 72-character maximum (the bcrypt truncation limit), a unique-constraint race backstop (23505 Postgres code caught in a try/catch), and pipes organisation through to the user_profiles insert.

The bridge commit (7baab52) is the technically interesting piece. backend/src/middleware/auth.ts drops the Authorization: Bearer pattern entirely. Instead it reads the authjs.session-token cookie (or __Secure-authjs.session-token in production), decodes it with next-auth/jwt's decode() using the shared AUTH_SECRET, and extracts sub and email from the JWT payload. frontend/next.config.ts adds a /api/backend/:path* rewrite so the browser sends the cookie automatically on every backend call. mikeApi.ts switches to relative URLs and credentials: "include".

There is a documented bug (9e99b3a): the decode() salt is hard-coded to the dev cookie name (authjs.session-token), so the production __Secure- variant will fail to decode. The comment says to fix this before deploying to HTTPS; it's not fixed in this branch. Anyone copying backend/src/middleware/auth.ts needs to handle both cookie name variants.

The user-profile route (c7d112e) migrates /user/me, /user/profile, and /user/account to Drizzle as the first end-to-end demo of the full stack.