fix: source CUDA tooling from Pixi

[aunjgr]

Description

Sirius's MO embedding profile already builds CUDA from Pixi, but two auxiliary tools still searched the host's /usr/local/cuda: the phase-22 sanitizer gate and the SF1000 patched-cuDF build helper. On hosts with only Pixi's toolkit, those tools could not run.

Explicitly lock cuda-sanitizer-api and the CUDA 13 libnvjitlink-dev header, resolve both tools from the activated Pixi prefix, and fail before clone/build if the prefix is missing or mismatched. The CUDA driver remains host-provided; no driver implementation is packaged. The benchmark README documents a dependency-only preflight.

Checklist

• Read CONTRIBUTING.md and ensure PR meets "reviewability" checklist
• Cover changes with new or existing tests
• Document configuration changes in code and summarize in the description above
• Update human and agent documentation (README.md, docs/, skills, CLAUDE.md)

Validation: pixi lock --check; pixi install --frozen -e mo; P22_SELFTEST=1 P22_UNITTEST_BIN=build/mo/extension/sirius/test/cpp/sirius_unittest pixi run --frozen -e mo bash test/scripts/sanitizer_gate_22.sh; SIRIUS_CUDA_PREFLIGHT_ONLY=1 pixi run --frozen -e mo bash bench/sf1000-repro/build-libcudf.sh; pixi run --frozen -e mo pre-commit run -a. Full SF1000 patched-cuDF compilation and GPU sanitizer workload were not run.

References

Refs matrixorigin/matrixone#29203.

[aunjgr]

Withdrawn after provenance review: the hard-coded CUDA paths in these optional scripts were introduced by upstream Sirius commits sirius-db#732 and sirius-db#1371, not by the MO embedding work. Per the integration scope, upstream tooling should remain unchanged; the MO embedding build itself resolves CUDA from Pixi.