feat(xla): derive image context floors for LLaVA and Qwen2-VL

[inureyes]

Summary

Derive the worst-case image context floor for LLaVA and Qwen2-VL, so the OpenXLA startup guard stops falling through for two families that are qualified for the image path. Only Molmo2 had a formula, so LLaVA and Qwen2-VL still hit the failure the guard exists to prevent: run the whole vision tower, then reject at admission.

Both derivations follow this codebase, not the upstream families

Worth stating up front, because the divergence will look like a bug to anyone comparing against HF behavior:

• LLaVA applies no anyres grid here. load_llava_host_preprocessor computes mm_tokens_per_image.unwrap_or((image_size / patch_size)^2), and llava_token_block_info sets use_boi_eoi: false with empty prefix and suffix lists, so one image contributes exactly that count with no framing tokens and no shape dependence. llava_next checkpoints route to the same loader unless the text backbone is Granite, so they get the same formula.
• Qwen2-VL does not read max_pixels from preprocessor_config.json. qwen_vl_processor builds the processor with Qwen2VLProcessor::new, which sets the pixel bounds from constructor defaults and never opens that file. A max_pixels key in a checkpoint has no effect on what this path admits, so a floor derived from one would be a number the runtime does not honor.

The guard has to predict what the runtime will emit, so both follow the code. The pixel bounds are now named constants in the processor module, shared with the derivation, so the two cannot drift apart.

The Qwen2-VL floor exposed a flaw in the guard's message

Qwen2-VL expansion depends on image shape across a 256x range:

224x224   ->    64 tokens
768x1024  ->   999 tokens   (an ordinary photograph)
4000x4000 -> 16384 tokens   (at the pixel cap)

The old message told the operator to set the capacity to the floor "to serve images". At Molmo2's 1834 that is followable. At 16384 it is not, given that capacity is the sequence length every decode step attends over and measured decode already falls from 3.18 to 1.41 tok/s between 256 and 2048.

It was also wrong on its own terms. A capacity below the floor serves every image whose expansion fits it, which on this family is most real images. The old text implied such a configuration could serve none.

The message now asks for the largest expansion the operator intends to serve, says what a smaller value does, and notes that oversized images are still rejected only after their vision tower has run. It carries no issue numbers, because a GitHub reference is not useful to someone reading a server startup failure.

This edits ensure_xla_image_context_capacity, which the issue placed out of scope. That scope line was written before the 256x range was known, and shipping a correct number attached to impossible advice would have been worse than the gap it closes.

Validation

Unit tests: 26 passed in host_preprocessor, existing Qwen2-VL processor test still green.

Five real checkpoints, floors derived from each one's own config.json:

checkpoint	family	floor
llava-1.5-7b-4bit	LlavaVLM	576
llava-interleave-qwen-0.5b-bf16	LlavaVLM	729
llava-next-mistral-7b-4bit	LlavaVLM	576
qwen2-vl-2b	Qwen2VL	16384
qwen2-vl-2b-4bit	Qwen2VL	16384

The Qwen2-VL check runs the real smart_resize and compute_grid_thw over extreme shapes rather than re-evaluating the derivation, which would only have proved the formula agrees with itself. The worst observed count equals the floor exactly, so the bound is tight rather than a safe overestimate. That direction matters: a floor above the true maximum only costs a larger graph, while one below reinstates the late-admission failure.

The real-checkpoint test is #[ignore] and reads MLXCEL_FLOOR_MODEL, so it does not require checkpoints to be present, and it loads no weights.

Recorded caveat

If the LLaVA host preprocessor ever implements an anyres grid, the LLaVA floor stops being a fixed per-image count and has to be revisited. The derivation is correct for the loader as it exists, not for the family in general. This is noted in the code rather than only here.

Closes #1272