fix(ocr): replace eval() with ast.literal_eval in deepseek_ocr coordinate parsing

[Ricardo-M-L]

What

`xinference/model/image/ocr/deepseek_ocr.py` had two `eval()` calls in the coordinate-extraction helpers:

Site	Old code
`extract_coordinates_and_label` (L231)	`cor_list = eval(ref_text[2])`
`extract_text_blocks` (L399)	`coords = eval(f"[{coords_str}]")`

In both, the string passed to `eval()` is a substring extracted from the OCR model's text output. OCR output is LLM-generated and attacker-influenceable through the source document or prompt, so an OCR response shaped like

```
<|ref|>x<|/ref|><|det|>[[import('os').system('id')]]<|/det|>
```

would have its payload executed by the host process when the result is parsed for downstream rendering / block extraction.

Why this matters

Same RCE shape as the merged tool-parser fix #4786 — that PR covered `xinference/model/llm/` but did not reach the image OCR path. Anyone running the deepseek_ocr model on attacker-influenced documents would silently be executing whatever Python the model emits inside `<|det|>...<|/det|>` brackets.

Fix

Replace both calls with `ast.literal_eval`, which only accepts Python literal structures (lists, tuples, numbers, strings, …) and refuses calls, attribute access, and imports. The expected coordinate strings are list literals like `[[10, 20, 30, 40]]`, which `literal_eval` parses identically to `eval`, so behavior on legitimate input is unchanged.

Exception handling is also tightened from a bare `except Exception` to the specific `ValueError` / `SyntaxError` that `literal_eval` raises (plus `IndexError` / `TypeError` in the first helper, which indexes `ref_text[1]`/`ref_text[2]`).

```python

Before

cor_list = eval(ref_text[2])

After

OCR output is LLM-generated and attacker-influenceable. literal_eval

only accepts Python literal structures and rejects code execution.

cor_list = ast.literal_eval(ref_text[2])
```

Tests

Adds `xinference/model/image/ocr/tests/test_deepseek_ocr_safe_eval.py` with cases that pin the security guarantee:

• ✅ Legitimate single and multi coordinate lists still parse.
• ✅ A payload of `import('pathlib').Path(...).write_text(...)` is rejected with no side effect (verified by checking a tmp_path sentinel file is never created).
• ✅ Attribute-walking payloads (`().class.bases[0]...`) are rejected.
• ✅ Malformed truncated input does not crash callers.
• ✅ A malicious block followed by a valid block in the same OCR response still allows the valid block to surface (parser does not abort on a bad block).

The test module `pytest.importorskip`s `torch` / `PIL` / `torchvision` so it is safely skipped in environments without the OCR runtime, but runs fully in CI.

Notes

• Same fix shape as merged PR fix: replace eval() with safe alternatives to prevent RCE in tool parsers #4786 (`fix: replace eval() with safe alternatives to prevent RCE in tool parsers`). This PR closes the remaining `eval()` site that fix: replace eval() with safe alternatives to prevent RCE in tool parsers #4786 didn't reach.
• No external behavior change — `literal_eval` is a strict subset of `eval` for the expected inputs.

`ruff check` passes on all touched files.

[qinxuye]

Tests failed.