Phase 2: migrate chat.ts, projectChat.ts, chatTools.ts onto pg

Closes the chat and assistant-tools surface. ~20 db.from sites across
chatTools.ts (3285 lines) converted to parameterised SQL, plus full
rewrites of routes/chat.ts and routes/projectChat.ts.

Key changes:
- routes/chat.ts:
  - GET /chat replaces the .or() PostgREST filter that
    string-concatenated project ids with
    'user_id = $1 OR project_id = ANY($2::uuid[])', still
    parameter-safe.
  - chat_messages inserts now JSON.stringify content/annotations so
    they reach Postgres as proper JSONB rather than relying on the
    Supabase client's serialisation.
- routes/projectChat.ts:
  - Full rewrite. Same flow, all queries through pg.
- lib/chatTools.ts:
  - enrichWithPriorEvents, generateDocx, loadCurrentVersionBytes,
    runEditDocument (with multi-row bulk INSERT for document_edits
    using positional placeholders), the replicate_document inline
    block (bulk INSERTs for documents and document_versions with
    multi-row VALUES + per-row UPDATE for current_version_id),
    buildDocContext, buildProjectDocContext, and buildWorkflowStore
    all converted.
  - Public functions that previously required a Supabase client
    keep their db parameter as optional and ignored, so the
    still-Supabase tabular.ts keeps compiling unchanged until its
    own migration.

End-to-end verification against Postgres 16:
- /ready ok with db: true.
- GET /chat initially empty.
- POST /chat/create returns a uuid.
- GET /chat/:id returns chat + empty messages array.
- PATCH rename applies.
- GET /chat lists 1 with the new title.
- DELETE returns 204.
- GET /chat returns empty.
- Regression: /projects, /workflows, /single-documents still pass.

Remaining on Supabase JS: tabular.ts (19). After that, drop
@supabase/supabase-js from the backend entirely.