Auth stripped to a hardcoded stub, then partially rebuilt on Supabase JWT

The first commit (e6568f8) is a single-tenant kiosk move: requireAuth stops calling Supabase and sets res.locals.userId = 'internal' unconditionally. The login and signup pages are deleted. AuthContext becomes a constant. And backend/src/lib/access.ts - the module that checks project ownership and shared-with membership - is rewritten so every function returns { ok: true, isOwner: true } regardless of inputs. The commit message says "all users 'internal' for now," making the placeholder intent explicit, though it also bundles an unrelated SQL change adding a workflow jsonb column to chat_messages.

A few hours later, 2217a5d adds a functional login page: email/password form with Carbonleo branding (#292629 background, #FEEA0F accent), AuthContext wired to supabase.auth.onAuthStateChange, layout redirecting unauthenticated users to /login. Then fffe4396 restores JWT verification in requireAuth via createServerSupabase().auth.getUser(token), so real user IDs flow through again.

The problem: access.ts was never restored. After fffe4396, the backend correctly identifies who is logged in, then hands every project and document to every authenticated user anyway. checkProjectAccess, ensureDocAccess, ensureReviewAccess, and listAccessibleProjectIds all still return hardcoded success. In a single-tenant internal deployment that may be fine; in any multi-user setup it is a straightforward authorization bypass, not a placeholder.

The login page UI in 2217a5d is reusable if you want a Supabase email/password flow with custom branding. The auth-stripping commit is not. Anyone considering fffe4396 should also restore the ownership and sharing logic from upstream or write their own, or they will ship authenticated-but-unscoped data access.