bug(vision): CLIPModel load is broken by a removed transformers kwarg, and the only test that notices flips on runner contention #14935

Vision models fail to load at all, and the only test that notices is a coin flip

Found while triaging #14930, in the marker-excluded suite's own runs.

The real defect: vision is dead

Every construction of MultiModalProcessor logs this and carries on:

ERROR multimodal_processor.base.vision:vision.py:146 Failed to load vision models:
CLIPModel.__init__() got an unexpected keyword argument 'resume_download'

resume_download was removed from the transformers model-loading API. The call site
passes it, CLIPModel.__init__ rejects it, the exception is caught and logged, and
initialisation continues as if nothing happened. So no vision model is ever loaded
— not in CI, and not anywhere else running this version of transformers. Nothing
fails, nothing alerts; the capability is simply absent behind a log line.

This is the same shape as the "major bump is a SET of breaks" pattern: a dependency
removed a kwarg, and the only surface that would have shown it swallows the error.

The symptom that surfaced it: a boundary-flaky benchmark

autobot-backend/system_benchmarks_performance_test.py::TestSystemPerformanceBenchmarks::test_system_startup_performance

start_time = time.time()
MultiModalProcessor()
processor_startup_time = (time.time() - start_time) * 1000
assert processor_startup_time < 500.0, f"Multimodal processor startup too slow: {processor_startup_time}ms"

Two consecutive marker-suite runs, identical code for this test:

The measured quantity sits within ~8% of the budget, so it flips on ordinary
GitHub-hosted runner contention. Worse, what it measures is mostly the failed
model load above — a duration governed by how long transformers takes to reach its
own TypeError, not by the constructor's work. The assertion's message names
"Multimodal processor startup"; that is not what the number represents while vision is
broken.

performance_benchmarks_test.py already carries this lesson in its own header
(#13162): wall-clock budgets on a shared runner measure contention rather than code.

Why this matters now

#14930 / #14933 make the marker-excluded suite report a real verdict and turn its 38
failures and errors into stated skips. The suite is now green — except that this one
assertion will redden it roughly half the time. A workflow that is red half the time is
a workflow nobody reads, which is precisely the habit .github/workflows/marker-tests.yml
warns against in its own header. Left alone, this single test re-installs it.

It was not fixed in #14933 deliberately: it is a pre-existing failure unrelated to that
PR's subject (it happened to pass in the "before" run), and the correct fix depends on a
decision this issue owns — see below. Relaxing the budget to make the board green is
explicitly the wrong move.

Acceptance

• CLIPModel is constructed with arguments the installed transformers accepts, and vision models actually load — proven by a test asserting a loaded model, not by the absence of a log line
• The vision-load failure stops being swallowed: a load that fails surfaces somewhere a human sees, rather than only in a debug log
• Audit the same call site family for other arguments removed in the same transformers change — a major bump is a set of breaks, not one
• test_system_startup_performance asserts something that cannot flip on runner contention: either measure the constructor without the optional model load, or drop the wall-clock budget for an assertion about what was built
• The marker-excluded suite runs green twice in a row

Related: #14930, #14933 (the suite this surfaced in), #13162 (the same wall-clock lesson,
already written down one file over).