Parse documents on a Celery parsing worker via a read_document tool

Replace the sandbox Docling extractor with read_document, backed by the in-process
backend parser (the same one ingestion uses) and offloaded to a dedicated
'parsing' Celery queue so it can run on GPU-capable workers with predictable RAM.
The tool resolves the input ref under the run-scoped gate, enqueues the parse,
and awaits it with a timeout (degrading to an error rather than hanging); the
worker independently re-resolves the artifact through the same gate and never
trusts a raw path. Untrusted files get the upload path's safeguards (extension
whitelist, size cap, sanitized temp file, cleanup). Options: output
(markdown/text/structured/chunks), ocr, pages, engine, max_chars, include_tables,
persist, json_schema. The workflow native-file 'extract' fallback now uses the
same worker path, so document parsing no longer needs the sandbox and works on
every backend.

Also fixes the branch's periodic-task test (the sandbox reaper made it 12) and
points the dev and e2e Celery workers at the parsing queue.

scripts/e2e/up.sh

@@ -276,7 +276,7 @@ log "starting Celery worker (solo pool)"
     PYTHONPATH="$REPO_ROOT${PYTHONPATH:+:$PYTHONPATH}" \
     PYTHONUNBUFFERED=1 \
     nohup "$PY_BIN" -m celery -A application.app.celery worker \
-        -l INFO --pool=solo \
+        -l INFO --pool=solo -Q docsgpt,parsing \
         --without-gossip --without-mingle --without-heartbeat \
         >"$CELERY_LOG" 2>&1 &
     echo $! > "$CELERY_PID"