Add Gemma 4 video tower support

[john-rocky]

Summary

Routes Gemma 4 video frames through the existing `vision_tower` as a batch (same encoder as images, just with a smaller per-frame soft-token budget) and performs text-level expansion of a `<|video|>` placeholder into a per-frame timestamped sequence — `mm:ss <start_of_image><|video|>×N<end_of_image>`, joined by spaces — matching the HF Gemma 4 reference processor.

Faithful to the Python reference in `mlx-vlm` Gemma 4 processor; the Swift-side simplification is a fixed-square video frame size (default 384×384) rather than aspect-preserving resize, so the existing pooler kernel grid (24/3 = 8) divides cleanly and per-frame token counts match the prompt placeholders exactly.

What's added

• `Gemma4Configuration` gains `video_token_id`, `vision_soft_tokens_per_video_frame` (default 64), and `video_frame_chunk_size` (default 4).
• `Gemma4ProcessorConfiguration` gains `video_seq_length`, `video_frame_size`, `video_max_frames` (default 16), `video_fps` (default 2.0), `boi_token`, `eoi_token`.
• `Gemma4VisionModel.callAsFunction` accepts an `outputLength` parameter that is forwarded to the pooler so video frames pool down to a smaller token budget than images.
• `Gemma4.getInputEmbeddings` accepts `pixelValuesVideos` and processes them in chunks of `video_frame_chunk_size` through the vision tower with `outputLength = visionSoftTokensPerVideoFrame`, calling `eval` between chunks so per-chunk attention masks can be released before the next chunk is built. Features are concatenated and scattered at `video_token_id` positions in the prompt embedding.
• `Gemma4Processor.prepare` samples frames at `video_fps` capped at `video_max_frames`, processes each through `CIImage.toSRGB().resampled(:method:).normalized(:_:)`, and rewrites the decoded prompt to splice in the per-frame timestamped soft-token sequence before re-encoding.
• `Gemma4MessageGenerator` emits one `<|video|>` literal text marker per video so the chat template tokenizes them as plain text and the processor expands them at the text level.

Why chunking + lower default frame count

The vision tower allocates an attention mask of shape `(batch, 1, max_patches, max_patches)`. With `max_patches = 2520` the mask alone is ~13 MB per frame, so a 32-frame batch peaks at ~400 MB before any layer activations — enough to OOM `gemma4-E2B` on iPhone alongside the language model. The chunked dispatch keeps peak memory roughly constant in frame count, and dropping the default to 16 frames adds headroom without sacrificing useful temporal coverage at `fps = 2`.

The `CIImage` chain change (`toSRGB().resampled().normalized()` instead of `MediaProcessing.apply` followed by `resampleBicubic`) avoids `MediaProcessing.apply`'s `bestFitScale` `transformed(by:)` step, which leaves the CIImage with a non-square extent that round-trips fine through most paths but trips `asMLXArray`'s bitmap render on iOS with `verify_image_parameters: invalid image bits/pixel or bytes/row`.

Token math

A 384×384 frame yields 24×24 = 576 patches. With Gemma 4's 3×3 pooling, kernel = √(576/64) = 3 (clean), output = 8×8 = 64 soft tokens per frame. `videoSeqLength` and `visionSoftTokensPerVideoFrame` both default to 64; override either via JSON if the model is published with a different budget — they must match.

Verification

• ✅ `swift build` clean.
• ✅ `xcodebuild MLXChatExample` builds for macOS arm64, generic iOS Simulator, and generic iOS Device against this branch.
• ✅ App launches on macOS without crash.
• ✅ On-device iOS verified — iPhone 17 Pro, `mlx-community/gemma-4-e2b-it-4bit`, 8 s video clip → 42.53 tok/s decode, transcript matched the video content. (After the chunking + frame-count + CIImage chain fixes; an earlier draft of this PR with `videoMaxFrames = 32` and the `MediaProcessing.apply`-based preprocess OOM'd / hit `verify_image_parameters` on the same device.)
• ⚠️ Companion ml-explore/mlx-swift-examples PR registers `gemma4:E2B` / `gemma4:E4B` in MLXChatExample.

Notes

• Image path is unchanged.
• Audio path (PR Add Gemma 4 audio tower support (ASR via Conformer encoder) #192) is orthogonal; this PR does not interact with `audio_tower`.
• The fixed video frame size is a deliberate Swift-side simplification of Python's aspect-preserving 70-token-budget pipeline. If a downstream model needs a different soft-token budget, override `vision_soft_tokens_per_video_frame` and `video_seq_length` together.