[CUDA] Build the CUDA argument lists in steps

[GoodOlClint]

Proposed changes

A readability/compile-cost cleanup in the CUDA build, and a follow-up to #413 ("Allowing SPM to compile on Linux with CUDA") — no behaviour change.

Three argument lists are assembled as long + chains of arrays. They are hard to read, awkward to extend, and expensive for the type checker, which has to solve the whole chain as one expression:

• Source/Encuda/encuda-compile.swift — the nvcc argument list (7 concatenations).
• Plugins/CudaBuild/plugin.swift — the encuda compile and encuda link argument lists, built inline inside createBuildCommands.

Each becomes stepwise appends into a local array, which is what the compiler's own diagnostic suggests when a chain does get too large. The plugin's two move into compileArguments and linkArguments helpers so createBuildCommands reads as a sequence of build commands rather than argument plumbing, and adding one more flag to either list is now a one-line change that can't tip the type checker over.

The concatenation order — and therefore the emitted command lines — is unchanged.

On Swift 6.2: these chains do exceed the 6.2 type checker's budget outright (error: the compiler is unable to type-check this expression in reasonable time), so this change is a prerequisite for building on that toolchain. It is not sufficient, and this PR should not be read as lowering the toolchain floor: SwiftPM 6.2 discards non-Swift files produced by a build-tool plugin (warning: Only Swift is supported for generated plugin source files at this time), so all ~95 generated .cpp files are dropped and every CUDA symbol goes undefined at link time. The swift-tools-version: 6.3 in #413 is load-bearing. Type-check cost and readability are the whole of the rationale here.

Verification

• pre-commit run --all-files — clean.
• scripts/verify-docs.sh — passes.
• xcodebuild build-for-testing -scheme mlx-swift-Package -destination 'platform=macOS' — builds; CmlxTests and MLXTests pass (Xcode 26.6, Swift 6.3.3).
• Exercised in a real CUDA build: swift build on an sm_121 device (DGX Spark / GB10, CUDA 13.0.88, Swift 6.3.3, aarch64) compiled all 95 .cu files and decoded Llama-3.2-1B-Instruct-4bit at 196.4 tok/s and gemma-4-12B-it-4bit at 23.0 tok/s.

Note CI does not cover the SwiftPM CUDA lane — linux_build_cmake_cuda builds via CMake — so the CUDA-side verification above is on-device rather than in CI.

Related

Two other follow-ups to #413 are open alongside this one, and all three touch Plugins/CudaBuild/plugin.swift. They are functionally independent, but whichever merges first will leave the others needing a trivial rebase — happy to reorder or stack them however you prefer:

• [CUDA] Allow selecting nvcc's host compiler, and invalidate on change #443 — selecting nvcc's host compiler (+ invalidating on change).
• [CUDA] Make the CUDA include roots configurable #444 — making the CUDA include roots configurable (CCCL / cudnn-frontend / CUTLASS).

Checklist

Put an x in the boxes that apply.

• I have read the CONTRIBUTING document
• I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
• I have added tests that prove my fix is effective or that my feature works — no test added: this is a behaviour-preserving refactor of argument-list construction; the existing build is the check, and the emitted command lines are unchanged.
• I have updated the necessary documentation (if needed) — no API or configuration change.

[davidkoski]

Change looks good to me. Thank you!