fix(ci): repair refresh-data workflow, triage stale security alerts

[Sagargupta16]

Part A: 12 open Dependabot alerts (8 keras, 4 python-multipart)

All 12 were false positives matched against a stale requirements.txt dependency-graph snapshot (keras 3.13.2, python-multipart 0.0.27, tensorflow 2.20.0) -- the same frozen snapshot already documented in .github/dependabot.yml. Verified at HEAD f705411:

• keras is pinned at 3.15.1 in requirements-ml.txt, the pyproject.toml ml extra, and both hash-pinned lock exports -- at or above every first-patched version (3.14.0 for chore(deps): update redis docker tag to v8.6 #118, 3.15.0 for chore(deps): update dependency node to v24 #119-chore: update security policy r1 #125). requirements.txt contains no keras at all.
• python-multipart was removed entirely in v2.2.0 (the API is JSON-only); git grep finds no reference in any manifest (chore(deps): update dependency msw to v2.12.7 #100-chore(deps): update dependency prettier to v3.8.0 #103).
• The dependency-graph SBOM confirms the stale entries coexist with the real ones (keras 3.13.2 AND 3.15.1, tensorflow 2.20.0 AND 2.21.0).

Action taken: dismissed all 12 alerts via the API with per-alert justifications -- keras as inaccurate, python-multipart as not_used. No dependency version needed changing, so no pins moved. uv lock --check passes, uv sync --extra ml succeeds, keras 3.15.1 imports, the FastAPI app loads, and all 59 backend tests pass.

If alerts respawn from the frozen snapshot (two in-repo fixes have already failed to purge it: the forced re-parse in 03aa6b6 and the pip ecosystem declaration in dependabot.yml), the remaining options are repo-admin actions: disable and re-enable the dependency graph under Settings > Advanced Security, or ask GitHub support to drop the stale requirements.txt snapshot.

Alert	Package	Severity	Patched	Status
#125	keras	medium	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#124	keras	medium	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#123	keras	high	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#122	keras	low	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#121	keras	high	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#120	keras	medium	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#119	keras	medium	3.15.0	dismissed (inaccurate) -- repo has 3.15.1
#118	keras	high	3.14.0	dismissed (inaccurate) -- repo has 3.15.1
#103	python-multipart	high	0.0.30	dismissed (not_used) -- removed in 2.2.0
#102	python-multipart	low	0.0.31	dismissed (not_used) -- removed in 2.2.0
#101	python-multipart	low	0.0.30	dismissed (not_used) -- removed in 2.2.0
#100	python-multipart	low	0.0.30	dismissed (not_used) -- removed in 2.2.0

Part B: failing Refresh training data workflow

Failed on all three scheduled runs (Aug 17, 24, 31). Root cause from run 33390403866: peter-evans/create-pull-request v7.0.8 runs git remote prune origin against the credentials actions/checkout@v6 persists, so git sends a duplicate Authorization header and GitHub rejects it with HTTP 400 (fatal: unable to access ... error: 400, exit 128). The data-fetch step succeeded on every failed run; only PR creation broke. Not a secret issue -- the workflow uses the default GITHUB_TOKEN.

Fix: bump create-pull-request to v8.1.1 (SHA-pinned 5f6978f), which targets checkout@v6 and restricts the prune to self-hosted runners (fixed upstream in v7.0.11, PR #4250). Verify by dispatching the workflow manually after merge (gh workflow run refresh-data.yml).

Also

• CHANGELOG 2.3.1 entry; version bumped in pyproject.toml, client/package.json, main.py, uv.lock.

Tested

• uv lock --check passes; uv sync and uv sync --extra ml succeed
• keras 3.15.1 imports; FastAPI app module loads
• 59/59 backend tests pass
• refresh-data.yml parses as valid YAML

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud