fix: OCR embedded image regions selectively instead of full-page render

[AdemBoukhris457]

Closes #220

Summary

• Fixes OCR on text-heavy pages with embedded images: each qualifying image is rendered and OCR'd via render_image_object() instead of rendering and OCRing the entire page
• Sparse pages (< 100 chars native text) still use full-page OCR (scanned / image-only pages)
• Maps OCR bboxes from image pixel space back to page viewport coordinates

Motivation

Previously, any page with an embedded image (logo, icon, figure) triggered full-page OCR even when the page already had plenty of native text. image_bounds() was only used as a boolean trigger; image boxes were never used for cropping or regional OCR.

This caused unnecessary render + OCR cost on decks and reports where every slide has a small logo.

Documentation alignment

Code now matches documented selective OCR behavior:

• AGENTS.md: "OCR only runs on embedded images where text extraction failed, not the entire document."
• LiteParseConfig: runs on text-sparse pages and embedded images — image OCR is now scoped to those regions, not the whole page

Behavior change

Page condition	Before	After
< 100 chars	Full-page OCR	Full-page OCR (unchanged)
≥ 100 chars + images	Full-page OCR	Per-image OCR only
≥ 100 chars, no images	Skip	Skip (unchanged)

Test plan

• cargo test -p liteparse --no-default-features ocr_merge (8/8 pass, incl. bbox mapping tests)
• Parse a text-heavy PDF with a small logo per page — confirm faster OCR vs previous full-page behavior
• Parse a scanned/sparse PDF — confirm full-page OCR still runs
• Parse same file with --no-ocr — unchanged

[logan-markewich]

I don't disagree with this change, but some complex/annoying merge conflicts popped up based on past PRs

[AdemBoukhris457]

I don't disagree with this change, but some complex/annoying merge conflicts popped up based on past PRs

@logan-markewich Just rebased on main and took care of the conflicts. Should be good to go now

[adarshmadrecha]

Just noting a edge case scenario, Sometimes, the PDF creating software will split the image and them embed it into the PDF.

Check this PDF for instance
Uploading 02.pdf…

Interesting pages

• 32 -- Here the Image is occupying almost half the page. In this case, I would suggest only picking up per image OCR
• 39 -- Here the Image is occupying almost all the area of the page. Except for the Header which appears on all the pages, there is NO text. In this case, I would suggest Full-page OCR. Technically, there are 3 images on this page because it got split.