fix(vision): gate fusion behind ocr so render-pdfium and vision build

[chintans]

Problem

Neither --features render-pdfium nor --features vision compiles on main:

$ cargo build --features render-pdfium
error[E0432]: unresolved import `crate::tables::complete_table_markdown_from_items`
  --> src/vision/fusion.rs

mod fusion is gated on vision, but it imports complete_table_markdown_from_items, which is gated on ocr. So any feature set that turns on vision without also turning on ocr fails to build — including the renderer-only set.

This matters because src/vision/mod.rs's own doc comment describes exactly that split as intentional:

so browser WASM, text-only consumers, and renderer-only users take on no model-management or inference dependencies

Renderer-only is a real use case: rasterising a couple of pages to hand to a vision model, without pulling in ONNX Runtime and the OCR model stack.

Fix

Gate fusion on ocr instead of vision, matching pipeline and image_analysis.

Every public item in fusion is OCR-shaped (fuse_ocr_pages, ocr_page_to_markdown, FusedPageMarkdown, FusedPages, OcrFusionError, OcrFusionOptions) and its internals are driven only by the ocr-gated pipeline. And since vision alone never built, nothing could have depended on fusion without ocr — so this removes no reachable API.

The same reasoning applies to the OCR-only native-text probe in vision::pdfium (PdfiumTextPage, extract_text_pages, text_chars_to_items), which is only called from the OCR pipeline. Gating it on ocr keeps a renderer-only build free of dead code — without it, cargo clippy --features render-pdfium -- -D warnings fails on unused items.

I first tried the other direction (widening the complete-tables chain to vision). It compiled, but clippy then reported ~6 dead-code errors under render-pdfium, which is the signal that the dependency was pointing the wrong way. Happy to switch to that shape instead if you'd rather keep fusion available without ocr — it's a larger diff.

Why CI didn't catch it

The workflow only built default and ocr. Both happen to satisfy the import, so a vision-gated module depending on an ocr-gated item broke the intermediate feature sets silently. This PR adds vision and render-pdfium clippy jobs as the regression guard.

Verification

• cargo clippy -- -D warnings passes for default, vision, render-pdfium, ocr, ocr-oar, model-cache
• cargo test passes for default, vision, render-pdfium, ocr
• End-to-end render under render-pdfium alone (no ocr), with PDFIUM_LIB_PATH set: rendered 1 page(s); page 2 is 992x1400

3 files changed, 23 insertions(+), 3 deletions(-).

🤖 Generated with Claude Code

---

Summary by cubic

Fixes the render-pdfium and vision feature builds by gating the fusion module on ocr instead of vision.

• The fusion module imports complete_table_markdown_from_items, which is gated on ocr, so vision without ocr never compiled.
• OCR-only native-text helpers in vision::pdfium are gated on ocr to keep renderer-only builds free of dead code.
• CI now runs clippy for vision and render-pdfium to catch this regression.

^{Written for commit 185c753. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Shadow auto-approve: would auto-approve. Gates fusion and OCR-only helpers behind ocr instead of vision to fix the broken vision- and render-pdfium-only builds; adds CI coverage for those feature sets.

Re-trigger cubic</sub>