Frontend Supabase auth removed - hooks and components switch to cookie credentials

Three hooks are updated first (dde61d2): useFetchSingleDoc, useFetchDocxBytes, and useDocumentVersions each contained 10-15 lines of supabase.auth.getSession() followed by a conditional Authorization: Bearer header and a hard-coded NEXT_PUBLIC_API_BASE_URL base. All three collapse to a relative URL plus { credentials: "include" }. The diff is largely deletions.

Four components follow (fca7df4): DocPanel, DocxView, EditCard, and AssistantMessage. Same pattern. A small non-obvious fix in AssistantMessage: download URLs from tool output were being prepended with API_BASE to form an absolute URL; they now get /api/backend prepended instead, and the comment explains the security intent (only backend-relative download URLs are accepted to prevent leaking the cookie off-origin).

frontend/src/lib/auth.ts is rewritten (c3bdd90) to use Auth.js's auth() server function instead of validating a Bearer token via Supabase. The function signature drops the NextRequest argument entirely - Auth.js reads the cookie itself. The new implementation is 10 lines; the old was 55.

A new PATCH /user/me endpoint lands on the backend (10d66a5) to support profile updates. It validates each field individually, builds a Partial<typeof userProfiles.$inferInsert> update object, rejects empty-update requests with 400, and returns 404 if no row is found. This lets UserProfileContext (125982e) load and update the profile through the API rather than directly querying Supabase, which was the last blocker before frontend/src/lib/supabase.ts could be deleted.