Reported from production within the hour: `Qwen3.5-9B` now REFUSES pictures,
"served without a vision tower" — the exact opposite of what the vision
loading was for.

transformers' `_LazyAutoMapping.get` is not `dict.get`. Its signature is
`get(self, key, default)` and `default` is REQUIRED, so

    AutoModelForImageTextToText._model_mapping.get(type(cfg))

raises TypeError. `is_vision_checkpoint` caught it and answered "no vision
class" — for every checkpoint, always. Every vision model therefore loaded as
text, and then had its pictures refused by the guard added for exactly that
case. The probe I verified it with passed two arguments, so it tested a call
the code does not make.

Two tests now call what the code calls: one with a stub whose `get` mirrors
the required `default`, and one through the real mapping with a config class
this transformers actually ships.

The silence was the other half. `is_vision_checkpoint` returned False without
a word, so the engine log said nothing at all and the only symptom was a 400
that blamed the model's configuration — which was fine. `vision_report` now
carries the reason at every step, a checkpoint that looks like a vision model
and is not loaded as one says so in the log, and the refusal quotes what was
actually found rather than listing three things it might be.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC