/v1/ocr has accepted `lang` since the beginning, with the comment "reserved": it
was parsed and dropped. A client asking for Italian got whatever the install was
configured for and no way to tell.

It is honoured now, on /v1/ocr, /v1/ocr/batch and the pipeline step, with
precedence request > ocr.<engine>_lang > ocr.lang > auto. The request beats the
engine-specific setting deliberately: that setting is an install's default, while
a caller naming a language knows something about the document in hand. Asking for
`auto` explicitly is NOT the same as sending nothing, so an install configured
for Italian can still be asked to work it out.

The default is auto-recognition rather than any particular language, because a
server that has not been told what it is reading should not assume one. For
surya-2, olmOCR and docTR that is simply what they already do: they are
multilingual and have NO language input to constrain -- surya-2's entire prompt is
"OCR this block image to HTML." and its own module warns the wording is the
training-time contract, so there is nowhere to put a language and nothing to gain.
Rather than let `lang` look effective everywhere, every response now carries what
was applied AND whether the engine that served could act on it
("lang": "it", "lang_applied": false), and /v1/ocr/engines reports the same per
engine so a client can choose before sending.

PaddleOCR is the exception that shapes the rest. It loads a language-specific
recognition model and its options are sent once at load, so an instance is built
for one language and cannot be re-languaged. Hence: `auto` becomes
ocr.paddle_auto_lang (default `latin`, a SCRIPT family rather than detection --
PaddleOCR's own default is `ch`, a worse guess for most documents than no guess),
and paddle gets one pool per language, keyed on the model it is BUILT with so
`auto` and `latin` share a pool instead of loading it twice. The multilingual
engines keep a single pool whatever is asked. That is not tidiness: a
language-keyed pool is a second set of loaded instances holding VRAM, and a
production install runs 24 surya instances. Both pool-iteration sites already use
.values(), and _Pool keeps the plain engine name, so eviction and the VRAM
releaser handle the new keys unchanged.

ocr.lang's shipped default moves "it" -> "auto"; installs that set it explicitly
(Digesta production does) are unaffected. ocr.surya_langs stays as the legacy
setting it is -- it reaches only the <=0.17 recognition API and does nothing on
the pod path.

21 tests. The 8 failures in test_broker_config / test_studio_composed_surfaces /
test_whisper_server_local_models are pre-existing, verified at HEAD.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW