fix(preflight): accept 0.33.x-dynres in mlx-cuda, as #218 did for cuda-dynres-903

[glennneuber]

#218 widened cuda-dynres-903 for the v0.33.0 sync. mlx-cuda was left behind and needs the same widening.

Both are lineage-tracking profiles keyed on the containerised -dynres stamp, both describe the same CUDA host, and the sync moves that host's builds to 0.33.x.

0.32.14-rc0-dynres-20-geb0ad43   old True    new True
0.33.0-dynres-3-gabc1234         old False   new True
0.33.0-rc1-dynres-1-gdeadbee     old False   new True

What is deliberately left alone

Every profile pinned to an exact baseline: mlx-metal (0.32.5-maxusai), mlx-metal-0-32-14, metal-0-32-14, metal, cpu, rocm-0-32-1-dynres, cuda-dynres-005.

Those are tight on purpose — mlx-metal's own comment reads "tightened at first baseline". A new version there wants a new profile with re-measured expectations, not a wider pattern (ADR 0011). Only the two lineage profiles track a moving version by design.

Why this recurred

This is the same defect #175 fixed for mlx-cuda at its creation — the pattern could not match the artifact it describes, so --platform mlx-cuda fails to resolve a profile at all. That is the bad failure shape: the gate becomes unreachable rather than red.

It recurred because that fix was version-specific. Worth naming the general shape: a version pattern is the one field that breaks by standing still — every other expectation stays correct until something changes, this one goes stale on a bump that touches nothing else.

--platform mlx-cuda currently passes on the CUDA host (7 PASS / 3 SKIP, gemma4 measured), so there is a real gate to lose here. #217's criterion 4 runs the CUDA preflight after the image build; without this it would error on profile resolution instead of exercising the row.

verdict gate 50/50.

🤖 Generated with Claude Code

[glennneuber]

Added a guard commit, because this is the second occurrence of one defect and the third is otherwise a matter of time.

cuda-dynres-903 and mlx-cuda describe one host — both keyed on the containerised -dynres stamp of the same CUDA machine, chosen between by --platform rather than by version — so their patterns drifting apart is always a bug. Now asserted directly, with a second test that the widening was not swept into the baseline-pinned profiles (mlx-metal, metal-0-32-14, cpu, rocm-0-32-1-dynres), since ADR 0011 wants a new profile with re-measured expectations there rather than a looser regex.

Verified by reintroducing the exact #218 state — widen one, leave the other:

AssertionError: 2 != 1 : lineage profiles drifted:
  {'cuda-dynres-903': '^0\.3[23]\....', 'mlx-cuda': '^0\.32\....'}

The failure names both patterns side by side, so the next person sees which one is stale rather than that something is wrong.

verdict gate 52/52.

The docstring records why this class earns a test at all, and it is the part I would keep if the rest were trimmed: the failure is silent in the worst way. A stale pattern does not make --platform mlx-cuda go red — it fails to resolve a profile, so the gate becomes unreachable rather than failing. Every other expectation in this file stays correct until something changes; a version pattern is the one field that breaks by standing still.