Bump pixi-build-cmake cap to 0.4.2 for pixi 0.71 (#96)

[joshkamm]

Fixes #96.

Problem

pixi 0.71 negotiates build-API version 5. The pinned pixi-build-cmake = ">=0.3.6,<=0.3.8" only allows backends requiring API v4 (0.3.7/0.3.8) or v2 (0.3.6), so the dependency solve fails before any compile:

pixi-build-cmake >=0.3.6,<=0.3.8 cannot be installed ... pixi-build-api-version: no candidates

Fix

Raise the bounded cap to the tested 0.4.2 (API v5). We deliberately keep an upper cap — backend updates have broken builds before (#50, #71/ZEST#64) — this just moves it to a known-good version rather than removing it.

The new range >=0.3.6,<=0.4.2 spans both v4 and v5 backends, and pixi-build-api-version is itself a solver dependency, so each pixi version auto-selects a compatible backend in range.

Verification (local, Perlmutter)

Clean pixi install of this repo:

• pixi 0.71.0 → Instantiated backend pixi-build-cmake@0.4.2, negotiated API version 5 ✅ (was the failing case; now resolves and compiles)
• pixi 0.70.0 → Instantiated backend pixi-build-cmake@0.3.14, negotiated API version 4 ✅ (floor still works)

(Both then hit a pre-existing, unrelated cublas_v2.h-not-found compile error specific to the login-node CUDA env — identical under both pixi versions, so not introduced by this change.)

requires-pixi = ">=0.60.0" unchanged; the widened range only adds backward compatibility.

Coordinated change & CI

• Identical one-line bump across the four repos sharing this pin: SlaterGPU, ZEST (#100), XCtera, molecularGSM. ZEST/XCtera build SlaterGPU from source, so they need this merged for a full pixi-0.71 build.
• The monthly use-latest-pixi schedule (added in Support multiple pixi versions via build backend version range #71) is the intended early-warning. It hasn't flagged 0.71 yet only because 0.71 released 2026-06-24 and the last scheduled run was 2026-06-19; the next run (2026-07-01) would have caught it. Merging this before then turns that run into a validation instead of a failure.