fix(safe-synthesizer): repair runtime setup dependency resolution

[marcusds]

Summary

nemo safe-synthesizer runtime setup was aborting at its final uv pip check gate with 6 incompatibilities. The causes were workspace-level dependency overrides and install steps that skipped required packages — not the installer logic itself. All 6 are now resolved.

Changes

Dep	Problem	Fix
gunicorn	Plugin installed with --no-deps, so its declared gunicorn was never pulled	Add to RUNTIME_EXTRA_REQUIREMENTS
diskcache	vLLM imports it for structured-output decoding and hard-pins 5.6.3, but the workspace [tool.uv].override-dependencies strips it globally for CVE-2025-69872	Install into the isolated runtime venv with --no-config (bypasses the override for this one package; global mitigation stays intact)
setuptools	Override >=78.1.1 (unbounded) resolved to 83, violating torch's setuptools<82	Bound override to >=78.1.1,<82 (nemo-safe-synthesizer needs >=80 → lands on 80.x–81.x)
datasets	Cap <=4.3.0 conflicts with nemo-safe-synthesizer[engine] (>=4.8.4) and trl (>=4.7.0)	Raise to >=4.8.5,<5 (jailbreak-detect already declares >=4.8.5); regenerate bundle + relock
nvidia-cusparselt-cu12	On aarch64/SBSA the correct wheel (manylinux2014_sbsa) is misreported by uv pip check as "built for a different platform" — it loads and CUDA works	Filter this one known-benign line in the final check; any other incompatibility still fails setup

Why diskcache uses --no-config instead of re-enabling it globally

There is no patched diskcache — 5.6.3 is the latest release (Aug 2023, unmaintained) and vLLM hard-pins it. The global override removes it with the rationale "transitive via ragas but not imported," which is false for this runtime. Rather than reintroduce the CVE workspace-wide, the runtime venv installs it scoped, so every other package keeps the mitigation. The CVE requires attacker write-access to the local cache dir — acceptable for a single-user GPU runtime.

Why the cusparselt line is filtered rather than fixed

The host is aarch64/SBSA (Grace). The installed nvidia-cusparselt-cu12 0.7.1 wheel is tagged py3-none-manylinux2014_sbsa — the correct aarch64 wheel that torch requires. Its metadata is internally inconsistent (Root-Is-Purelib: true plus a platform tag), so uv pip check misreads it. No version change can fix a correct wheel, so the check tolerates exactly this line and nothing else.

Notes for reviewers

• datasets 4.3.0 → 4.8.5 is platform-wide. uv lock resolves cleanly, but that only proves resolvability. Customizer / evaluator / jailbreak-detect deserve a functional smoke test before merge. Capped at <5 deliberately to avoid the datasets 5.0.0 major jump that unbounded >=4.8.5 floated to.
• Large uv.lock diff (−487) is safe. On a clean tree uv lock produces zero diff, so this is the deterministic result of the datasets bump. Every removed line is a wheel for armv7l/ppc64le/riscv64/s390x — platforms already excluded by [tool.uv].environments. No x86_64/aarch64/darwin-arm64 wheels dropped. uv lock --check passes.
• Gate stays fatal. The final check still raises on any real incompatibility; it only tolerates the single cusparselt platform-tag false-positive.
• Verified by applying the resolutions to the existing aarch64 runtime venv (6 → 0 blocking incompatibilities) and running uv lock --check + the plugin unit tests (11/11).

🤖 Generated with Claude Code

[github-actions]

Suite	Lines Covered	Line Rate	Branch Rate
Unit Tests	27117/34832	77.8%	62.1%
Integration Tests	15921/33544	47.5%	19.9%