fix: derive crop box from coordinate extent in save_elements

[badGarnet]

save_elements assumed points[0] and points[2] were always the top-left and bottom-right corners. For elements whose coordinates carry (or were converted from) a y-up orientation, that ordering inverts the PIL crop box and raises ValueError: Coordinate 'lower' is less than 'upper'. The error was silently swallowed, so the figure/table image was dropped.

The crop box is now computed from the min/max of all coordinate points, so it's always valid regardless of point ordering.

Changes

• pdf_image_utils.save_elements: use min/max over all points instead of fixed corner indices
• Added a regression test for inverted/rotated coordinate ordering
• CHANGELOG + version bump to 0.22.35

---

Summary by cubic

Fix image cropping in pdf_image_utils.save_elements by deriving the crop box from the coordinate extent. This prevents the PIL "Coordinate 'lower' is less than 'upper'" error and stops figure/table images from being dropped.

• Bug Fixes
  • Compute the crop box with min/max over all points instead of assuming fixed corners.
  • Add a regression test for inverted/rotated coordinate ordering.

^{Written for commit 0ea49ae. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 4 files

<sub>Shadow auto-approve: would auto-approve. The change is a targeted bug fix in a utility function that replaces hardcoded corner indices with min/max extents, eliminating a silent crop-box inversion bug without altering core logic or adding risk.

Re-trigger cubic</sub>