Fix Dependabot alerts: re-lock and bump vulnerable pip dependencies

[ishubhamvashist]

Summary

Resolves 15 of 26 open Dependabot alerts by re-generating uv.lock and bumping the affected transitive dependencies to versions that satisfy each advisory's patched-version requirement. The remaining 11 alerts have no upstream fix available (fixed_in is null) and are left open with reasons documented below.

Root cause found and fixed first: uv.lock was stale relative to pyproject.toml. Commit "Relaxed python reqs" changed requires-python from >=3.11,<=3.11.14 to >=3.11 in pyproject.toml but never regenerated the lockfile, so uv.lock still carried the old bounded requires-python and its associated platform markers. This made uv lock --check fail outright, independent of any security bump. Regenerating the lock against the current pyproject.toml fixed that drift (no version changes from this step alone).

On top of the corrected lock, targeted uv lock --upgrade-package <name> bumps were applied:

Package	Before	After	Alerts fixed
transformers	4.57.6	5.14.1	#102, #99, #34
soupsieve	2.8.1	2.8.4	#101, #100
GitPython	3.1.46	3.1.52	#54, #53, #51, #43, #42
nltk	3.9.2	3.10.0	#38, #15, #14, #9
Pygments	2.19.2	2.20.0	#21

All five are transitive dependencies (not listed directly in pyproject.toml) pulled in via datasets, inspect-ai, rich, wandb, textarena, etc. No application code imports nltk, GitPython, or Pygments directly, so the blast radius of these bumps is limited to whatever depends on them internally.

huggingface_hub was transitively bumped 0.36.0 -> 1.16.1 as a side effect of the transformers resolution (a major version jump). I checked this specifically since it's a bigger jump: the app's direct huggingface_hub imports (server/hf_upload.py: HfApi, upload_file, upload_folder, HfHubHTTPError; workloads/mcp_support/*.py: HfApi) all still import cleanly against 1.16.1 in an isolated venv test.

Only uv.lock was changed. pyproject.toml was not touched (its requires-python was already correct; only the lock needed regenerating).

Left unresolved (no fix available or bump not warranted)

• vllm (#96, #95, #94, #93, #92) — fixed_in: null on all five advisories, i.e. no patched version exists upstream. Also, this app imports vllm's internal, version-specific APIs extensively, so I deliberately did not force an unrelated version bump here — it would add real install/compat risk without closing any alert.
• torch (#64) — fixed_in: null, no fix available.
• nltk (#89, #50, Teacher fetch + truncating long trajectories + deepspeed + weight sync save every 5 + fix hf upload + cleanup #16, Update Python version to 3.11, add output log file, and modify depend… #13) — these specific CVEs affect all released nltk versions per the advisory (still fixed_in: null); nltk was bumped to the latest release (3.10.0) anyway as part of fixing the other nltk alerts, but that doesn't close these.
• diskcache (Custom trainer #8) — fixed_in: null, current version (5.6.3) is already the latest release.

Testing performed

• uv lock --check passes against the regenerated lock.
• Wrote a small script comparing every alert's fixed_in against the resolved lockfile version (proper version-tuple comparison, not string comparison): all 15 alerts with a real advertised fix are now satisfied; 0 unresolved among those with a fix.
• Full uv sync is not possible on macOS without a GPU in this environment: vllm is an unconditional core dependency (pyproject.toml dependencies, not an optional extra) and pulls Linux/NVIDIA-only wheels (e.g. nvidia-cudnn-frontend) that have no macOS build. I reproduced the exact same failure on a fresh, unmodified clone of main to confirm this is pre-existing and unrelated to this change, not something introduced here.
• Installed the five bumped packages together with huggingface_hub/datasets in an isolated venv (bypassing the vllm/torch/GPU blocker) to sanity-check the actual dependency graph resolves without conflicts and everything imports, including the app's real huggingface_hub import sites.
• This repo has no test suite and no lint config beyond [tool.ruff] line-length = 100 (no CI workflows either), so there was nothing further to run.

Risk to flag before merging

• The huggingface_hub 0.36 -> 1.16 major bump is the biggest change in this PR by version-distance. I verified import-level compatibility for the app's direct usages, but did not (and could not, without a GPU) run the actual model-loading/upload code paths end-to-end.
• GPU-based testing of the vllm/torch/transformers stack was not possible in this environment and should happen before merge, given this app is a synthetic-data-generation client built directly on vllm/transformers internals.