Found while writing the Digesta dev the answer to "which field names does
0.3.51 actually honour" -- a question that could not be answered honestly
because of these two.

/v1/ocr/batch never accepted max_tokens or max_continuations. A batch is how a
caller sends real work, so the budgets were accepted only on the path nobody
benchmarks: every claim since 0.3.49 that "/v1/ocr and /v1/ocr/batch take these
per request" was half wrong, docs included. FastAPI drops an unknown form field
in silence, which is the same trap this feature existed to close -- the caller
sets max_tokens on every batch and is never told it did nothing. The dev's
measurements at "max_tokens=8000/4000/2000" were therefore all taken at the
CONFIGURED value, whatever that was at the time.

And /v1/ocr's route decorator was attached to the _page_opts HELPER rather than
to create_ocr, because 0.3.49 inserted the helper between the decorator and its
function. FastAPI registered the helper as the handler, so the endpoint existed,
answered, and was not the OCR endpoint. Nothing failed at import; no test looked
at the route table.

16 tests, 12 of which fail against the pre-fix code: the route resolves to
create_ocr, _page_opts is not registered as a handler, both paths take both
budgets, each defaults to None (0 is meaningful for both -- no cap override,
resumption off), negatives clamp, and the batch path is asserted to FORWARD
them, since a signature that accepts a field proves nothing about using it.
Checked against the route table and signatures, so they need no engine or GPU.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW