fix(setup,docs): rebuild locally built images, name OCR_DEEPSEEK_URL

Both setup scripts start with `compose pull && compose up -d`. In the local
compose file backend and worker are build-only services, so `up -d` builds
only when no image exists yet: a rerun that switches OCR on wrote
INSTALL_TESSERACT=true to .env and then reused the image built without it,
leaving OCR_ENABLED=true with no engine. Build explicitly on the local
compose path; the hub path stays pull-only, its services have no build stage.

The OCR message named OCR_ENGINE=deepseek but not OCR_DEEPSEEK_URL, whose
default (localhost:11434) resolves to the container, not the host.

deployment/sandbox/README.md still described Docling as already present in
application/requirements.txt.

deployment/sandbox/README.md

@@ -188,8 +188,10 @@ Daytona render output matches the Jupyter-backend output.
 
 Document reading no longer runs in this sandbox. The `read_document` tool and the
 workflow native-file extract branch enqueue a `parse_document` Celery task that
-parses the document **in the backend** (Docling, already in
-`application/requirements.txt`) and awaits the result. The task is routed to a
+parses the document **in the backend** (the `DOC_PARSER_ENGINE` parser — anydoc
+by default; Docling only when the optional
+`application/requirements-docling.txt` extra is installed) and awaits the
+result. The task is routed to a
 dedicated **`parsing` queue** (`settings.DOCUMENT_PARSE_QUEUE`, default
 `"parsing"`) so a parse enqueued from inside a Celery worker (headless/scheduled
 agent) is served by a separate worker and never self-deadlocks the awaiting one.