fix(knowledge): retry transient PaddleOCR congestion

[yaojin3616]

Summary

Gitee issue IKEM87 reports that an image uploaded to Knowledge Space is immediately marked failed when PaddleOCR returns HTTP 503 with errorCode=10010 (task submission queue is full).

The upload and file-state workflow is working as designed; the failure is in the parse step. PaddleOcrLoader treated transient provider congestion exactly like a permanent parse error and therefore moved the knowledge file directly to the failed state.

Changes

• Retry transient PaddleOCR HTTP responses (429/502/503/504) and provider queue/rate-limit codes (10010/12002).
• Apply the same bounded exponential-backoff behavior to synchronous and asynchronous parser calls.
• Keep non-transient errors and the final exhausted response unchanged so the existing worker failure handling remains intact.
• Add configurable max_retries and retry_backoff settings with conservative defaults (3 retries, 1-second initial delay).
• Add regression coverage for recovery, non-retryable errors, retry exhaustion, and async calls.

Verification

• ruff check passed for all changed Python files.
• pytest --confcutdir=test/knowledge/rag test/knowledge/rag/test_paddleocr_retry.py -q: 4 passed.
• scripts/arch-guard.sh: passed.

Refs: Gitee issue IKEM87 (https://gitee.com/Data-Elem_1/dashboard/issues?id=IKEM87)