fix(ios): bypass CIContext+createCGImage in MLKVisionImage to fix 300+ MiB IOSurface leak

[Toker38]

Summary

pixelBufferToVisionImage instantiates a fresh CIContext per frame and renders via createCGImage(_:from:). Each call inserts a CI::SurfaceCacheEntry that the system never releases under sustained camera streaming — leaking ~3.5 MiB of VM: IOSurface per call (one 720p BGRA frame buffer). On a real device this reaches 300+ MiB in 60 seconds and continues to climb until the OS terminates the app.

This PR replaces the CoreImage round-trip with VisionImage(buffer: CMSampleBuffer) — the same path used by Google's official MLKit iOS sample. CoreImage is no longer involved, so the SurfaceCacheEntry is never created.

Fixes #863. Likely also addresses #708 and #790 on iOS.

Why a shared CIContext is not enough

Per the Apple Developer Forums thread on this exact symptom, @autoreleasepool blocks, sharing a single CIContext, and explicit CGImageRelease are listed as not confirmed working for this leak. The cache entry retention happens at the IOAccelerator layer, beyond ARC's reach. The only effective mitigation is to avoid createCGImage entirely — which is what VisionImage(buffer:) does.

Measurements (Instruments → Allocations on iOS, --release build)

Workload: camera ^0.11.x, ImageFormatGroup.bgra8888, ResolutionPreset.high (720p), FaceDetector.processImage at ~3 FPS, no face in frame, 60 s sustained.

Before

Generation	Duration	IOSurface growth	Allocations
A (warmup)	0–25 s	136 MiB	161
B	25–64 s	341 MiB	97
C	64–86 s	186 MiB	53

Each surface is exactly 3.52 MiB = 1280 × 720 × 4 (BGRA frame buffer). Net: ~8.5 MiB/sec of unbounded IOSurface growth.

Stack trace (largest persistent allocation):

IOSurfaceClientCreateChild
-[IOSurface initWithProperties:]
IOSurfaceCreate
CreateCachedSurface
CI::SurfaceCacheEntry::SurfaceCacheEntry
CI::ProviderNode::surfaceForROI
CI::Context::render
-[CIContext(_createCGImageInternal) _createCGImage:fromRect:format:premultiplied:colorSpace:deferred:renderCallback:]
-[CIContext(createCGImage) createCGImage:fromRect:]
+[MLKVisionImage(FlutterPlugin) pixelBufferToVisionImage:]    <-- plugin entry
+[MLKVisionImage(FlutterPlugin) bytesToVisionImage:]
-[GoogleMlKitFaceDetectionPlugin handleDetection:result:]

After (CMSampleBuffer path)

VM: IOSurface growth in 60 s drops from 341 MiB → near baseline (no observable accumulation per generation). Surfaces that the camera pipeline holds for active frames are still allocated normally; the per-processImage cache entries are gone.

Detection accuracy and latency are unchanged — MLKit's vision detectors consume CMSampleBuffer natively at the same speed as UIImage-backed vision images.

Implementation notes

• VisionImage(buffer:) requires a CMSampleBuffer, which we build from the CVPixelBuffer via CMVideoFormatDescriptionCreateForImageBuffer + CMSampleBufferCreateForImageBuffer. No CoreImage allocations are made.
• kCMTimeInvalid / kCMTimeZero timing is appropriate for a single-frame buffer that's not part of a continuous decode session.
• CMVideoFormatDescription and CMSampleBuffer are managed by Swift ARC for CFTypes — no manual CFRelease needed.
• Failure paths return nil (matching the existing nil-returning pattern in this file) so callers degrade gracefully instead of crashing.
• CoreMedia is added as an explicit import.

Test plan

• Verified on iPhone (iOS 26.2, real device, --release build) under sustained 60 s camera stream with face detection — VM: IOSurface growth eliminated.
• Verified detection results unchanged (face detection accepts CMSampleBuffer-backed VisionImages).
• Maintainers' CI on packaged example app.