chore(ci): compile the OpenXLA feature combinations

[inureyes]

Summary

Add a CI job that compiles the OpenXLA feature combinations. Nothing did, and two defects reached main through the gap.

The gap

ci.yml runs deny, fmt, crate-version, kernel-dtype-key, MLX-pin and cross-repo-ref jobs and never builds the crate. pipeline-parallel-ci.yml runs clippy on default features. nightly-verify.yml runs clippy with metal,accelerate. The OpenXLA serve worker lives behind #[cfg(feature = "xla-iree")], so no check run has ever compiled it.

What got through:

defect	class	caught by
ModelRequest::PromptCacheWarmup not handled in the OpenXLA worker (#1273)	compile error, E0004	cargo check
dead load_weights_from_dir_with_filter re-export	unused_imports	warnings policy
integration tests could not link with cuda,xla-iree (#1275)	link error	not covered, see below

Both of the first two were found by hand while rebasing an unrelated branch, not by any gate.

Why the GB10 runner

xla-iree links a C shim against a prebuilt IREE runtime. scripts/iree/setup-cuda.sh provisions it by building the runtime from source against a pinned revision, which is far too slow to do per PR from scratch. The GB10 runner already holds that build under ~/.cache/mlxcel/iree-cuda-<version> and the script is idempotent, so a warm runner reuses it and only a fresh one pays the one-time cost. xla-diagnostics additionally implies cuda, which points at the same host. That removes the provisioning question #1270 raised: no actions cache keyed on the IREE revision and no container image is needed.

Why it denies unused_imports and not every warning

Measured on the current tree, cargo clippy --features cuda,xla-iree --lib --tests -- -D warnings fails with four errors in mlxcel-xla alone, before reaching mlxcel, and cargo check --all-targets reports about ten dead-code warnings across both crates. A job that is red the day it lands gets ignored and stops being a gate at all.

unused_imports is the exact lint class of the dead re-export, and compile errors cover the other defect, so both historical breaks are caught without first clearing that backlog. Broadening to -D warnings needs the cleanup and is separate work.

Verified locally with the job's own commands and RUSTFLAGS, both green:

RUSTFLAGS="-D unused_imports" cargo check --features cuda,xla-iree --all-targets                  -> 0
RUSTFLAGS="-D unused_imports" cargo check --no-default-features --features xla-diagnostics --all-targets -> 0

What it deliberately does not cover

Recorded in the workflow file rather than left to be discovered later:

• No test execution. This is a compile gate. Running the XLA suites needs a GPU not contended with development work on the same host.
• No full warning policy, for the reason above.
• No macOS or IREE_DIST build. Neither has a runner with the required distribution. This is why fix(build): link libc after the IREE archives so integration tests link #1275's link failure would still not be caught: cargo check never links, so a compile gate cannot see it.

Also here

Two dead-code warnings that this repository's own Molmo2 parity test introduced under the non-diagnostics feature set are silenced, so the new gate starts from a clean tree rather than needing an exception on arrival.

The gate was observed catching the defect, not just passing

A job that only ever passes is not evidence that it catches anything, so the check-run history on this PR shows it in all three states:

commit	change	OpenXLA feature compile
763bc8a0	the job as proposed	SUCCESS
6f193333	ModelRequest::PromptCacheWarmup arm removed, reintroducing the exact defect that reached main	FAILURE
f88709bc	revert	SUCCESS

The failing run reported the same error the gap let through:

error[E0004]: non-exhaustive patterns:
  `model_provider::ModelRequest::PromptCacheWarmup { .. }` not covered

The middle commit and its revert stay in the branch history on purpose: squashed into main they cancel out, and until then they are the evidence.

Closes #1270