feat(auth): wire login and signup pages to backend API

[Ndifreke000]

Closes #12

Summary

Completes the first full-stack auth vertical slice by connecting the existing login/signup UI to the NestJS backend.

• src/lib/api/auth.ts — new typed auth module with login(), signup(), logout(), and extractApiErrorMessage(). Both mutation functions call the backend, then store the JWT and user profile so subsequent API calls are authenticated immediately.
• LoginForm — now calls login() instead of raw api.post. Real API error messages (NestJS validation arrays are joined; 401 maps to a credential-specific message; network failures show a connectivity message). Added role="alert" on the error paragraph for screen readers.
• SignupForm — now calls signup(). Fixes a bug where api.setCurrentUser() was never called after signup, so the user profile was never persisted. 409 Conflict maps to an email-already-in-use message. Same real-error-message surfacing as login.
• .env.example — documents the required NEXT_PUBLIC_API_URL variable (force-committed since .gitignore excluded .env* patterns).

What's in scope

Deliverable	Status
lib/api/auth.ts with login() and signup()	✅
Token stored on success (localStorage + cookie via existing setAuthCookie)	✅
Current-user stored on success	✅ (signup was missing this — fixed)
API validation errors surfaced in form UI	✅
Network failure messaging	✅ (inline error; see note below)
Redirect to /dashboard after login/signup	✅
Redirect param honoured on login	✅ (existing ?redirect= logic preserved)
.env.example updated	✅

Notes

Token storage tradeoff: Tokens are stored in localStorage (readable by JS) and mirrored into a non-httpOnly cookie (used by middleware.ts for SSR route protection). An httpOnly-only approach would require a Next.js API route acting as a proxy to set the cookie server-side. The current dual-storage approach is the simplest path consistent with the existing client.ts architecture; the tradeoff is documented in src/lib/api/README.md.

Toast notifications: No toast library is currently in the project's dependencies. Network failures are displayed inline in the form's existing error area (consistent with how validation and API errors are shown) to avoid pulling in a new dependency. Adding sonner or similar can be a follow-up if the team decides to standardise toast-based feedback.

CORS: The backend must allow http://localhost:3000 (or wherever the frontend runs) as an origin. Set NEXT_PUBLIC_API_URL in .env.local to point at the backend.