ci: run pixi locked in the source-build workflow

`ci-pixi-source-test.yml` used `setup-pixi` with `run-install: false` and
plain `pixi run` everywhere, so nothing pinned CI to the committed lock
files. If a `pixi.toml` changes without a matching `pixi lock`, pixi's
default behaviour is to silently re-solve and rewrite `pixi.lock` in
place -- CI then builds and tests an environment that is *not* the one
committed to the repo, goes green, and the stale lock only surfaces for
the next developer.

Set `PIXI_LOCKED: "true"` at the workflow level so pixi aborts with
"lock file not up-to-date with the workspace" instead.

Why an env var rather than `--locked` on each command: the root test and
docs tasks dispatch into the sub-package manifests via nested
`pixi run --manifest-path ...`. A flag on the outer command does not
reach those child processes; the environment variable does.

Why `--locked` and not `pixi lock --check`: `--locked` compares the lock
against the manifest only and does not re-solve against the channels, so
it stays green when a floating dependency gets a new upstream release.
`pixi lock --check` re-solves, and would go red spontaneously whenever
conda-forge publishes -- `benchmarks/cuda_core` fails it today for
exactly that reason (cuda-pathfinder 1.5.6 -> 1.6.0), with no change to
its manifest.

Verified locally:
- `PIXI_LOCKED=true pixi run -e cu13 test-pathfinder` passes today
  (1095 passed, 4 skipped), including the nested manifest dispatch.
- With a dependency added to `cuda_pathfinder/pixi.toml` and no re-lock,
  the same command fails fast with "lock file not up-to-date with the
  workspace"; without the variable, pixi re-solves and rewrites the lock.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: rparolin

.github/workflows/ci-pixi-source-test.yml

@@ -58,6 +58,22 @@ env:
   # prefix-dev/pixi#6285 + #6123) also bumps the pixi.lock format to v7.
   PIXI_VERSION: "v0.73.0"
 
+  # Fail fast when a pixi.toml changed without a matching `pixi lock`, instead
+  # of silently re-solving. Without this, `pixi run` updates the lock file in
+  # place and CI tests an environment that is NOT the one committed to the
+  # repo -- so a stale lock passes CI and only breaks for the next developer.
+  #
+  # Set as an env var rather than a `--locked` flag on each command because the
+  # root test/docs tasks dispatch into the sub-package manifests via nested
+  # `pixi run --manifest-path ...`; the variable is inherited by those child
+  # processes, a flag on the outer command is not.
+  #
+  # `--locked` compares the lock against the manifest only. It does not re-solve
+  # against the channels, so it stays green when a floating dependency gets a
+  # new upstream release -- unlike `pixi lock --check`, which would go red
+  # spontaneously whenever conda-forge publishes.
+  PIXI_LOCKED: "true"
+
 jobs:
   # ── PR guard: CPU-only build + import + placement smoke ──
   build-smoke: