build(i-g): Lockfile-Setup — deterministische Builds gegen Versionsdrift

(1) requirements.lock: 323 Pakete exakt gepinnt auf das heute getestete Set (fastapi==0.141.1, starlette==1.3.1, sqlalchemy==2.0.35, alembic==1.19.1, asyncpg==0.31.0, pydantic==2.13.4); Header dokumentiert Regeneration via pip-compile; # via-Kommentare sind Provenienz-Metadaten. (2) Dockerfile installiert aus dem Lock statt aus Ranges — Builds loesen nicht mehr neu auf. (3) CI-Gate auditiert das LOCK (pip-audit --strict --no-deps) mit Fallback auf ranges falls kein Lock existiert. (4) deploy-guide.md: Dependencies-aendern-Workflow dokumentiert.

Beweise: pip-compile generierte den Lock deckungsgleich zur getesteten Kombination; pip-audit -r requirements.lock = No known vulnerabilities; bash -n Syntax OK.

scripts/ci_pipeline.sh

@@ -96,7 +96,11 @@ else
 fi
 
 # ── 13. Dependency Scan (if pip-audit installed) ─────────────────────────────
-if command -v pip-audit &>/dev/null; then
+# Audit against the LOCKFILE (exact tested set), not the ranges file.
+if [ -f requirements.lock ] && command -v pip-audit &>/dev/null; then
+    check "Dependency Scan (pip-audit on lock)" "pip-audit -r requirements.lock --strict --no-deps 2>&1 | tail -5"
+    check "Pip Consistency (pip check)" "pip check"
+elif command -v pip-audit &>/dev/null; then
     check "Dependency Scan (pip-audit)" "pip-audit -r requirements.txt --strict 2>&1 | tail -5"
     check "Pip Consistency (pip check)" "pip check"
 else