Add deployment configs and DEPLOYMENT.md so the repo can be launched as a website

From the PR description

Summary

The repo already builds locally, but to actually launch it as a public website a few pieces were missing: a Dockerfile for the backend (with LibreOffice), a Dockerfile for the frontend, the Cloudflare wrangler config that npm run deploy relies on, a self-hosted docker-compose.yml, CI to verify builds, and an end-to-end deployment walkthrough.

This PR adds all of that without changing application code.

Changes

• backend/Dockerfile + backend/.dockerignore - multi-stage Debian-slim image, LibreOffice + fonts baked in, non-root user, /health healthcheck, tini as init.
• frontend/Dockerfile + frontend/.dockerignore - multi-stage build using Next.js standalone output, non-root user, NEXT_PUBLIC_* accepted as build args.
• frontend/next.config.ts - opt-in output: "standalone" controlled by NEXT_OUTPUT_MODE, so the Docker build path produces server.js while next dev/next start/the OpenNext Cloudflare path stay unaffected.
• frontend/wrangler.jsonc - Cloudflare Workers config matching the OpenNext output, with nodejs_compat enabled. Required for npm run deploy to actually work.
• docker-compose.yml at repo root - brings the whole stack up locally or on any Docker host. Frontend waits for the backend healthcheck.
• .github/workflows/ci.yml - parallel backend and frontend npm run build on every push/PR. Lint runs as a non-blocking check because the repo has a backlog of pre-existing warnings.
• DEPLOYMENT.md - end-to-end guide covering Supabase / R2 / model-provider setup, every required env var, and concrete deploy steps for Cloudflare Workers, Vercel, Fly.io, Render, Railway, and plain Docker, plus wiring and troubleshooting.
• README.md - short "Deployment" section linking to the new guide and showing the one-liner docker compose up --build path.

Why

The deployment story was implicit. With these additions a maintainer (or anyone forking) can pick a host, follow DEPLOYMENT.md, and have a working site without reverse-engineering env vars or build commands. The frontend Cloudflare deploy in particular was unusable before this PR because wrangler.jsonc was missing.

Testing

Locally on Node 20:

npm ci --prefix backend && npm run build --prefix backend   # ok
npm ci --prefix frontend                                    # ok
NEXT_PUBLIC_SUPABASE_URL=https://example.supabase.co \
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY=ci-anon-key \
NEXT_PUBLIC_API_BASE_URL=http://localhost:3001 \
NEXT_OUTPUT_MODE=standalone \
npm run build --prefix frontend                             # ok, .next/standalone/server.js produced

Both builds match what the new CI workflow runs. Docker images were not built in this environment (no Docker daemon available), but the Dockerfiles follow the same npm ci + npm run build paths that pass above, plus the standard Next.js standalone runtime layout.

Notes for the reviewer

• No application code is touched. The only product-code change is the conditional output field in next.config.ts, gated on an env var that is unset by default.
• wrangler.jsonc uses the standard OpenNext output paths (.open-next/worker.js, .open-next/assets). If your account already has a Worker named mike, change the name field before deploying.
• The CI lint step is intentionally continue-on-error: true. Flipping it to blocking is a separate cleanup PR.