build(docker): slim backend image, static frontend image, -docling variant

Backend (arc53/docsgpt): 4.5 GB compressed -> 0.9 GB with both embedding
models and tiktoken baked in.
- torch/transformers gone from the default install (docling extra only).
- Ubuntu 24.04 ships python3.12: no deadsnakes PPA, no software-properties-
  common; every pin is a wheel, so no gcc/g++/rust in the builder.
- COPY --chown and a prefetch that runs as the process user replace the
  trailing chown -R, which duplicated the 600 MB model layer.
- .dockerignore keeps __pycache__, .coverage, local indexes and .env out.
- EXTRAS build arg (INSTALL_DOCLING kept as an alias); the docling variant
  also bakes docling's layout/table/RapidOCR models (DOCLING_ARTIFACTS_PATH)
  and tesseract, and drops only the discovery documents of Google APIs the
  app never builds.
- FLASK_DEBUG env removed (unused); OCI labels added.

Frontend (arc53/docsgpt-fe): 302 MB Vite dev server -> 25 MB static build
behind nginx. VITE_* variables are injected at container start into
/config.js and read through src/env.ts, so the image no longer needs a
rebuild per deployment; docker-compose.yaml keeps hot reload via the dev
target.

Publishing: every release and develop build now pushes a slim tag and a
-docling tag (docling engine + models + tesseract). docker-compose-hub.yaml
takes DOCSGPT_IMAGE_TAG / DOCSGPT_IMAGE_VARIANT; docker-compose-standalone.yaml
runs the stack from pre-built images without a checkout and is attached to
each release. setup.sh selects the -docling variant for OCR instead of
requiring a local build. A new workflow builds the image on PRs that touch
it and runs verify_offline under --network none; lint checks the exported
requirements match uv.lock.

docs/content/Guides/ocr.mdx

@@ -64,11 +64,17 @@ docker build --build-arg INSTALL_TESSERACT=true ./application
 `INSTALL_TESSERACT=true` in `.env` (or the shell) bakes tesseract plus the
 English pack into locally built backend and worker images; `setup.sh` writes
 it when you answer yes to the OCR question after choosing to build images
-locally. Pre-built Docker Hub images (`docker-compose-hub.yaml`) do not
-include it, so `setup.sh` leaves OCR at its default (off) for them; to OCR
-there, point `OCR_ENGINE=deepseek` at a DeepSeek-OCR endpoint or install
-`tesseract-ocr` in a derived image. With `OCR_ENABLED=true` and no binary on
-`PATH`, scanned pages fail with an install hint (text-layer documents are
+locally.
+
+With pre-built images the switch is the image variant: every tag is
+published twice, slim (`arc53/docsgpt:<tag>`) and `-docling`
+(`arc53/docsgpt:<tag>-docling`), and the latter bakes tesseract, the docling
+engine and its models in. Set `DOCSGPT_IMAGE_VARIANT=-docling` in `.env` for
+`docker-compose-hub.yaml` or `docker-compose-standalone.yaml`; `setup.sh`
+writes it when you answer yes to the OCR question with Docker Hub images.
+Alternatively point `OCR_ENGINE=deepseek` at a DeepSeek-OCR endpoint, which
+needs no system package. With `OCR_ENABLED=true` and no binary on `PATH`,
+scanned pages fail with an install hint (text-layer documents are
 unaffected).
 
 <Callout type="warning" emoji="⚠️">
@@ -88,19 +94,27 @@ docling is not part of the base install, and OCR does not need it (see
 output:
 
 ```bash
-pip install -r application/requirements-docling.txt
+pip install -r application/requirements-docling.txt   # or: uv sync --extra docling
 ```
 
-Docker images build without it by default; opt in with the build argument:
+That file is the core set plus the `docling` extra, exported from the same
+lock. On Linux it takes torch from the CPU-only PyTorch index, so the extra
+costs about 1.5 GB rather than the 2.7 GB the CUDA build of torch would; a
+GPU deployment can reinstall torch from PyPI on top.
+
+Pre-built images: use the `-docling` variant (`arc53/docsgpt:<tag>-docling`,
+`DOCSGPT_IMAGE_VARIANT=-docling` in `.env`), which also bakes docling's
+layout, table-structure and RapidOCR models in so the first parse does not
+download them. Local builds opt in with the build argument:
 
 ```bash
-docker build --build-arg INSTALL_DOCLING=true ./application
+docker build --build-arg EXTRAS=docling ./application
 ```
 
 `deployment/docker-compose.yaml` forwards the same switch, so setting
-`INSTALL_DOCLING=true` in `.env` (or the shell) bakes docling into locally
-built backend and worker images; `setup.sh` offers it as a follow-up to the
-OCR question. Compose reads build arguments from the shell or from the
+`EXTRAS=docling` (or the older `INSTALL_DOCLING=true`) in `.env` (or the
+shell) bakes docling into locally built backend and worker images; `setup.sh`
+offers it as a follow-up to the OCR question. Compose reads build arguments from the shell or from the
 `.env` you pass with `--env-file .env` (not from the containers' `env_file`),
 so build with `docker compose --env-file .env -f deployment/docker-compose.yaml build`
 as `setup.sh` does. Pre-built Docker Hub images (`docker-compose-hub.yaml`)