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.

docs/deploy-guide.md

@@ -29,6 +29,12 @@ bash /a0/usr/projects/leocrm/scripts/fast-deploy.sh full
 2. `git add -A && git commit -m '...' && git push origin main`
 3. Dann deploy
 
+## Dependencies aendern (Lockfile)
+- requirements.txt = gewuenschte Ranges; requirements.lock = exakt getestetes Set
+- Nach jeder Aenderung an requirements.txt: `pip install pip-tools && pip-compile requirements.txt -o requirements.lock`
+- Lock-Diff reviewen (welche transitiven Versionen ziehen die neuen Ranges?)
+- CI-Gate auditiert das LOCK: `pip-audit -r requirements.lock --strict --no-deps`
+
 ## Container-Info
 - Coolify App UUID: xf7smknlger3hvkrsb910tui (neu erstellt 2026-08-06)
 - Container-Name aendert sich bei jedem Coolify-Deploy (Suffix)