Move the whole pipeline into the browser, drop the server

Every stage now runs client-side: pdf.js renders, a per-pixel diff finds
the hidden ink, tesseract.js transcribes it on request, and pdf-lib
rebuilds the flattened export. The PDF goes from the file picker into
memory and back out as a download, and is never sent anywhere.

That makes the privacy claim structural rather than a promise. The
server is left with one route — a health check — so there is no code
path that can receive a document, nothing is persisted, and no account
exists. The OCR model and WASM are staged out of node_modules into
public/ at build time so the page never reaches a CDN either. Verified
in the browser: a full scan with OCR contacts exactly one origin, its
own, and POST /api/upload returns 404 in the built image.

Contrast stretching turned out to be the wrong method entirely. Text
painted in pure #FFFFFF rasterizes to bytes identical to blank paper, so
there is no difference in the image to amplify — and a page with black
body text already spans 0-255, so the old server-side normalize() was a
no-op. It could never have found the case it advertised.

So each page is rendered twice, on white and on black. White ink vanishes
into the first and blazes in the second; inverting the black-backed
render and taking the darker pixel of each pair puts every mark on the
page in view whatever colour it was drawn in. Confirmed against a PDF
carrying a genuine white-on-white payload: invisible in "as delivered",
flagged in vermilion in "revealed", and transcribed verbatim by OCR.
Pages that paint their own opaque background defeat the technique, so
that case is detected and reported as unreliable instead of showing a
page-sized false positive.

OCR is opt-in, as asked: it costs an ~8MB model download and runs at a
few seconds a page, so nothing is fetched until the box is ticked.

Consequences:
- Removed auth, Prisma, Postgres, the upload/render/pixel/ocr/export
  routes, the storage layer and the signed-in dashboard.
- Runtime dependencies drop from 13 to 6, all browser-capable; sharp,
  @napi-rs/canvas, next-auth, pg and the Prisma stack are all gone.
- compose is a single stateless service with no volumes and no config,
  the entrypoint and its migration step are gone, and the image drops
  from 868MB to 455MB.
- The landing page no longer describes the contrast method it used to
  claim, since that method provably does not work.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.env.example

@@ -1,29 +1,10 @@
-# Copy to .env at the repo root before running `docker compose up`.
-# Do NOT commit the real .env.
+# XRayPDF needs no configuration to run: it has no database, no auth and no
+# server-side processing. Both values below are optional conveniences for
+# docker compose, and the app itself reads neither.
 
-# --- Postgres (compose `postgres` service) ---
-POSTGRES_USER=xray
-POSTGRES_PASSWORD=change-me
-POSTGRES_DB=xray
-
-# --- App (compose `xray` service) ---
-# Must match the POSTGRES_* values above; host is the compose service name.
-DATABASE_URL=postgresql://xray:change-me@postgres:5432/xray?schema=public
-
-# NextAuth (v4)
-NEXTAUTH_SECRET=generate-a-long-random-string
-NEXTAUTH_URL=http://localhost:3000
-
-# Google OAuth credentials
-GOOGLE_CLIENT_ID=your-google-client-id
-GOOGLE_CLIENT_SECRET=your-google-client-secret
-
-# Where uploads + result images are stored inside the container (volume mount).
-STORAGE_DIR=/app/storage
-
-# --- Deployment knobs ---
 # Published image to run. Override to pin a tag or digest, e.g.
 # ghcr.io/geneticglitch1/xraypdf:v1.2.0
 XRAY_IMAGE=ghcr.io/geneticglitch1/xraypdf:latest
-# Host port the app is published on (container always listens on 3000).
+
+# Host port the app is published on (the container always listens on 3000).
 HOST_PORT=3000