/text has no size cap: a single bloated document can return megabytes to the caller #8

Split out of the bilingual-contract table bloat work (branch claude/contract-table-bloat-v5wikg), where a .docx laid out as one long table extracted at several times its content size.

Problem

POST /text (app/routes/document_routes.py:1114) concatenates every loaded Document into one string and returns it, with no bound on the result:

text_content = extract_text_from_documents(data, file_ext)
return {"text": text_content, ...}

There is no guard anywhere in the path. Whatever the loader produces is held in memory, serialised into the JSON response and handed to the caller. A pathological document — a table-heavy contract, a large spreadsheet, a long OCR'd PDF — can therefore blow up the caller's context window (or its own memory) with no warning and no way for the caller to tell that it happened.

The table-padding fix removes one cause of oversized output, not the class of problem.

Suggested fix

• A configurable cap (e.g. TEXT_EXTRACTION_MAX_CHARS), applied after extraction.
• On exceeding it, prefer a clear 413-style error naming the size and the limit over silent truncation; silent truncation hands the caller a contract that stops mid-clause with no indication of it.
• Log the extracted size per file either way, so oversized documents are visible in production. (The .docx path now logs Chars: N -> M after cleanup; the other loaders have nothing equivalent.)

Notes

Worth deciding explicitly whether the cap applies to /embed too, or only to /text — the embedding path chunks its input, so it degrades differently.