fix: avoid RapidOCR torch fallback in default OCR setup

[zeukid]

Summary

Fixes the default Docling OCR setup to use RapidOCR with ONNXRuntime instead of accidentally falling back to the torch backend when torch is present.

The torch backend remains available when explicitly requested with RapidOcrOptions(backend="torch"), but Auto OCR no longer selects it implicitly.

Issue resolved by this Pull Request:
Resolves #3580

Changes

• Updated docling-slim[standard] to include feat-ocr-rapidocr-onnx.
• Removed RapidOCR torch from Auto OCR fallback selection.
• Added regression tests for Auto OCR backend selection.
• Added packaging coverage to ensure the standard extra includes the ONNX RapidOCR path.
• Regenerated uv.lock.

[github-actions]

✅ DCO Check Passed

Thanks @zeukid, all your commits are properly signed off. 🎉

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[dolfim-ibm]

@zeukid can you please explain the reason for this PR?

The behavior of Docling until now is to avoid installing onnxrutime when not explicitly requested via an extra. We have already torch as a default dependency and we would like to avoid a second one.

This the reason for the fallback in the OCR selection.