Avoid full-frame copies in default OpenCV resize

[bghira]

Summary

• create OpenCV Mat headers over the existing contiguous ndarray input
• write resize output directly into the returned ndarray
• retain RGB, contiguity, and interpolation behavior while checking OpenCV dimension conversions

Root cause

The default resize API copied every input into an owned OpenCV Mat and copied every resized Mat back into a second ndarray allocation. Those memory passes dominated otherwise-fast OpenCV resize calls, especially for large images and batches.

Performance

Median local latency on Apple M3 Max:

• 1024x768 -> 512x384: 0.176 ms -> 0.033 ms
• 2048x1536 -> 1024x768: 0.567 ms -> 0.226 ms
• 4032x3024 -> 1024x768: 1.379 ms -> 0.435 ms
• batch of 16 at 1024x768 -> 512x384: 3.871 ms -> 1.046 ms

The default path is now within a few percent of batch_resize_images_zero_copy.

Validation

• cargo test --features opencv,simd (60 passed)
• Python test suite (68 passed)
• repository pre-commit hooks, including competitive performance benchmarks

[Copilot]

Pull request overview

This PR optimizes the default OpenCV-backed resize path by avoiding full-frame memory copies, creating lightweight cv::Mat headers over existing ndarray storage and resizing directly into the returned ndarray buffer.

Changes:

• Build zero-copy OpenCV Mat headers over contiguous ArrayView3<u8> input buffers.
• Preallocate the output Array3<u8> and resize directly into its backing memory.
• Remove the now-unneeded Mat→ndarray bulk-copy helper from this implementation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.