preflight: pin the MLX payload for the CUDA dynres profile

[glennneuber]

cuda-dynres-903 pins llama_cpp_build but carried no mlx_build, so mlx_payload_pin skipped on every CUDA preflight run: "profile records no mlx_build to assert against". These images ship mlx_cuda_v13 beside the llama.cpp payload, so the profile serves both stacks.

That is how the v0.34.0 fold's MLX bump (37c26e57 → ce916dbb) reached a preflight PASS with the MLX identity unasserted.

This PR

• pins mlx_build to MLX_VERSION at main a523d60b, the payload these expectations were measured on;
• widens test_every_measured_mlx_profile_pins_its_mlx_build, which only enforced profiles whose platform starts with mlx, to cover a profile that serves the MLX payload whatever its platform says.

Checked: python3 test_verdicts.py 102 pass, python3 test_summarizers.py 118 pass. With the pin removed the widened test fails, naming cuda-dynres-903 and saying mlx_payload_pin would skip.

Consequence, deliberately: an image whose MLX differs from the pin now fails this check instead of inheriting stale expectations. The v0.34.0 fold branch moves the pin to ce916dbb as part of its bump, with the preflight re-run on that payload.

🤖 Generated with Claude Code

[glennneuber]

Pushed a follow-up, 47c8156, after running the pinned profile against a real image.

What the run showed. Pinning mlx_build on a CUDA profile turns the check's SKIP into a failed run:

FAIL  mlx_payload_pin: no MLX engine-init line in the log window
FAIL=1  PASS=20  SKIP=7   VERDICT: FAIL

The check reads the MLX build from the runner's engine-init line, and a CUDA preflight loads llama.cpp models, so no MLX runner ever starts. The payload was exactly the pinned one — nothing was wrong but the evidence. As written, this PR would have turned every CUDA preflight red, the deploy candidate's included.

The follow-up. probes.mlx_build_payload reads the version string out of the shipped libmlx.so, which is what llama_cpp_build already does for llama-server: the payload's own identity rather than the version string of whatever is checked out. The engine-init line stays the first source, because only a live load can catch the binary/payload skew this check was written for, and the summary now names which source answered.

Four tests cover it, including the failing case above and that a live line still wins over the library. With the fallback disabled, the CUDA-run test fails (checked). python3 test_verdicts.py 106 pass.

[glennneuber]

Superseded by the v0.34.0 fold, #297, now merged as 19012a41.

Everything this PR proposed is on main, carried by two commits on the fold branch:

• 41e90fa4 — mlx_build added to [profiles.cuda-dynres-903], pinned to the fold's own MLX, ce916dbb, rather than this PR's 37c26e57.
• cbe0e9b7 — probes.mlx_build_payload() and the check_mlx_payload_pin fallback that reads the version out of the shipped libmlx.so, with the live engine-init line still preferred because only it catches binary/payload skew. Without that fallback the pin turned the CUDA preflight's SKIP into a FAIL, since a CUDA preflight never loads MLX.

Verified on the deploy candidate: PASS 21, SKIP 7, pin asserted. Closing as redundant, not as rejected — no work is lost.

🤖 Generated with Claude Code