Apply pending backend dependency bumps with regenerated lockfiles

[d3mocide]

Supersedes the four open backend dependabot PRs, applying the same bumps in a form that actually takes effect.

Bump	Supersedes
sqlalchemy 2.0.51 → 2.0.52	#286
litellm 1.94.1 → 1.96.2	#287
uvicorn[standard] 0.52.0 → 0.52.3	#288
alembic 1.18.5 → 1.19.1	#289

Why supersede rather than merge them

Each of those PRs changes exactly one line of backend/pyproject.toml and nothing else — no lockfile regeneration. Because CI installs --require-hashes from the lock and then runs pip install --no-deps -e ., pyproject's pins are never enforced against the lock. Merging them as written would change the declared versions without changing a single installed package.

That's not hypothetical: it's how fastapi, litellm and uvicorn ended up two or three releases behind their declared pins, which #292 corrects. This PR applies the same four bumps and regenerates both lockfiles, so they land for real.

Once this is green, #286–#289 can be closed as superseded.

Stacked on #292

Based on claude/backend-dep-audit-fixes (#292), not main, because it needs the corrected locks as a starting point. GitHub will retarget this to main automatically when #292 merges. Merge #292 first.

Relative to #292, exactly four versions move — the four bumps themselves. No transitive dependency changed:

alembic            1.18.5 -> 1.19.1
litellm            1.94.1 -> 1.96.2
sqlalchemy         2.0.51 -> 2.0.52
uvicorn[standard]  0.52.0 -> 0.52.3

Testing

Clean Python 3.12 venv, installed exactly as CI does:

• pip-audit — No known vulnerabilities found
• ruff check . — All checks passed
• mypy luma --ignore-missing-imports — Success, 78 source files
• pytest -x -q — 201 passed
• Lockfiles are idempotent under a plain pip-compile re-run, so Regenerate backend lockfiles to clear pip-audit failures, and assert they match pyproject #292's new drift check passes here.

alembic 1.18 → 1.19 is the one bump that touches machinery I can't fully exercise locally — the Migrations — apply & check job needs a live TimescaleDB. What I could verify: under alembic 1.19.1 and SQLAlchemy 2.0.52 the script directory loads all 36 revisions, resolves to a single head (0033_add_water_presets), and luma.db.models imports cleanly with all 29 tables. The migrations job on this PR is the real check on alembic upgrade head and alembic check — worth a look before merging.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KqXjgMRArAxubgd5f5UYgC

---

Generated by Claude Code

[d3mocide]

No checks will appear on this PR until #292 merges — that's expected, not a stuck run.

pr-checks.yml is gated on the base branch:

on:
  pull_request:
    branches: [main]

This PR is based on claude/backend-dep-audit-fixes (#292), so the filter excludes it and no workflow is dispatched at all. When #292 merges, GitHub retargets this PR to main automatically and the full suite runs on the next event.

So the sequence is: merge #292 → this retargets → CI runs here → close #286–#289 as superseded.

If you'd rather see a green run before merging anything, say so and I'll collapse both into a single PR against main instead — the tradeoff is that the CVE fix and these four bumps stop being separately revertable.

Meanwhile, #292 is green on all four jobs (run 34877012532), including the two that matter most here: Tests passed for the first time since Aug 10, and the new Check lockfiles match pyproject step passed in 19s.

---

Generated by Claude Code