ocr: olmOCR has to trust a pod's certificate itself, and U+FFFD is one token not two bytes (v0.3.22)

olmOCR could not reach a rented pod at all: CERTIFICATE_VERIFY_FAILED. A pod on
the direct-TCP path serves HTTPS with a certificate signed by THIS install's own
CA (codai/api/pod_tls.py), at a public IP that was not known when the certificate
was issued, so stock `requests` fails it twice over.

Surya never hit this because surya attaches through the fan-out gateway, which
learned to trust pod certificates in 0.3.16. olmOCR talks to the upstream the
dispatcher chose DIRECTLY, so it needed the same trust of its own -- and the gap
only surfaced when olmOCR was asked to cover for surya, which is exactly when a
fallback engine must not be the thing that is broken. It now goes through
codai/api/pod_http.py, which verifies https-to-a-bare-IP against our CA with the
hostname check off and hands every other URL -- localhost, a named server,
another coderai -- to requests untouched. Swept the rest of the tree: every other
raw requests call targets a localhost worker or RunPod's own public API, where
pod_http would be a pass-through anyway.

test_ocr_olmocr's HTTP-status test patched sys.modules["requests"] wholesale,
which now breaks pod_http's own import of it; it patches pod_http.post instead
and asserts the same two statuses.

Also records what the accent investigation actually established, because the
natural reading of U+FFFD is wrong and expensive. It is NOT a charset bug:
U+FFFD is a real entry in surya-ocr-2's vocabulary (id 65421 of 65425, the only
id that decodes to it), the tokenizer is WordLevel and character-level for Latin
so an accent cannot be split across tokens, and the decisive detail is the COUNT
-- a byte-level mis-decode yields TWO markers per accented letter (a-grave is two
UTF-8 bytes, each one undecodable), and what arrives is ONE. One marker is one
token. Every other hop was checked: _html_to_text is regex plus html.unescape and
survives literal and entity forms; the isolated-venv worker emits json.dumps with
ensure_ascii=True, so the pipe carries pure-ASCII escapes and the locale cannot
matter; the gateway forwards raw bytes.

And it corrects the previous commit's claim. Raising DPI is right on its own
merits -- 200 really was feeding surya 62% of the pixels it accepts -- but a
production document came back with the same markers at 200 AND at 300, which is
evidence against too-few-pixels being the whole story: a perception failure would
be stochastic, not every accent every time. The docs now say what distinguishes
the remaining candidates (the document's embedded scan resolution, which
`pdfimages -list` reports and which no rasterisation DPI can improve, versus the
serving stack) and how to tell them apart: OCR perfect synthetic Italian through
the same path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW