1.1.5 Implement sign-up / sign-in / reset-password pages from the mockup

Estimate: 32m · Depends on: 1.1.1, 1.1.2, 1.1.3, 1.1.4

Translate the approved mockup from 1.1.1 into real React pages, wired to the Better-Auth setup from 1.1.2, the user repository from 1.1.3, and the Google OAuth provider from 1.1.4. The mockup is the source of truth for the visual outcome — this subtask should not make new visual decisions; if something feels off in the mockup, raise it as a re-plan of 1.1.1 rather than diverging here.

Why depend on 1.1.4 (Google OAuth): the sign-up/sign-in pages ship with a working "Continue with Google" button, not a stub. Half-finished implementations that say "Google login coming soon" are explicitly disallowed by CLAUDE.md. The dependency forces ordering: Google OAuth lands before the pages, so when the pages are built the button is wired the first time.

What you'll do: Create /app/(auth)/sign-up/page.tsx, /app/(auth)/sign-in/page.tsx, /app/(auth)/reset-password/page.tsx. Each page composes Button, Input, Card from /components/ui/. Email/password submit handlers use Server Actions calling Better-Auth's server API; form state uses useFormState for error display. The "Continue with Google" button on sign-up + sign-in is a Button variant="secondary" whose onClick initiates Better-Auth's OAuth sign-in flow (signIn.social({ provider: "google" })); it shows a spinner during the redirect. Empty + loading + error states from the mockup must all render.

Acceptance criteria

• Three pages exist and render visually identical to /design/auth-screens.png (pixel-equivalence not required; visual-equivalence is).
• Sign-up: valid email + 8+ char password → user created, session cookie set, redirect to /app.
• Sign-up errors render inline: email already taken, password too short, network failure.
• Sign-in: valid creds → session, invalid → inline error "Email or password is wrong" (don't leak which).
• "Continue with Google" button is wired (not a stub) on both sign-up and sign-in pages: clicking initiates Better-Auth's Google OAuth flow; on success the user is redirected to /app with a session cookie set. Button shows a spinner during the redirect.
• Google OAuth errors (consent denied, missing creds in dev) render an inline error on the page the user was on (not a server 500).
• Reset-password request: form accepts an email, calls backend, shows the confirmation screen (regardless of whether the email exists — don't leak account existence).
• Loading states: submit buttons show spinner during the action; double-submit prevented.
• Accessible: every form field has a label; errors are aria-live="polite"; keyboard tab order is sensible (Google button is reachable via Tab before the email field).
• Mobile breakpoint matches the mockup.

Context refs

• /design/auth-screens.pen + /design/auth-screens.png — the mockup from 1.1.1
• /docs/design-system.md — token reference
• /components/ui/Button.tsx, Input.tsx, Card.tsx — primitives to compose
• /lib/auth/index.ts — Better-Auth instance + Google provider (from 1.1.2 + 1.1.4)
• /lib/users/repo.ts — user repository (from 1.1.3)
• Better-Auth client docs (fetched at prompt-gen time): client-side signIn helpers for credentials + social providers