The pod reported 'No module named surya.ocr' — an API that has not existed for
a year. The real error was two tiers up: the loader wrapped each version branch
in a bare except, so a failure INSIDE the right branch was swallowed and it fell
through to the oldest one. The reported error was from code that never should
have run.

The real error was surya 0.17.1's config class choking on transformers 5.17.
The pin came from a stale requirements-surya.txt. The local install — read from
its venv's dist-info — runs surya 0.22.1 on transformers 5.15, and works. Both
now pin 0.22.1.

0.22 dropped surya.foundation and takes RecognitionPredictor() alone, which the
loader already handled — but only as a fallback reached by swallowed exception.
It now selects the API by what IMPORTS: foundation present is 0.17, absent is
0.22 (or pre-0.17). Verified loading 0.22.1 through the engine class on the pod
stack beside docTR.

tts-xtts: coqui's TTS(name) splits on '/' and wants its own four-part catalogue
name; a HuggingFace id has two parts and fails 'expected 4, got 2'. The service
translates (coqui/XTTS-v2 -> tts_models/multilingual/multi-dataset/xtts_v2),
verified against coqui's catalogue. This means XTTS through _CoquiBackend had
never worked with an HF id anywhere, not only on a pod.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY