feat: Cloud-Fundament - Auth, Persistenz und Mandanten-Trennung

- SQLite-Store (app/store.py) hinter Store-Interface: Nutzer + Sessions persistent
- Bearer-Token-Auth (app/auth.py); Nutzerverwaltung via Admin-Key (POST /api/admin/users)
- GET /api/me, PUT /api/me/prefs (dauerhafte Nutzer-Praeferenzen)
- chat/speak/transcribe/sessions auth-geschuetzt; Mandanten-Trennung (fremde Session -> 403)
- Route-Aufloesung: Defaults < Profil < ENV < Nutzer-Prefs < Session < Request
- SessionManager (in-memory) durch Store ersetzt
- AUTH_ENABLED-Schalter (prod an, dev/Tests aus); DB_PATH/ADMIN_API_KEY
- Doku aktualisiert (README, BEDIENUNGSANLEITUNG, Architektur, deploy-env); data/ gitignored
- Tests: 29 gruen (Auth, Mandanten, Persistenz, Routing)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

BEDIENUNGSANLEITUNG.md

@@ -196,11 +196,66 @@ Start mit klarer Meldung ab.
 
 ---
 
-## 10. Fehlerbehebung
+## 10. Authentifizierung & Mehrbenutzer
+
+Im Produktivbetrieb ist `AUTH_ENABLED=true` (Standard). Dann brauchen
+`chat`/`speak`/`transcribe`/`sessions`/`me` ein **Bearer-Token pro Nutzer**.
+Nutzer und Sessions werden in einer SQLite-Datei gespeichert (`DB_PATH`, Standard
+`data/voice-assistant.db`).
+
+**Schritt 1 — Admin-Schlüssel setzen** (nur über die Umgebung):
+
+```bash
+export ADMIN_API_KEY=ein-langes-geheimnis
+```
+
+**Schritt 2 — Nutzer anlegen** (Token erscheint **nur einmal**, sicher notieren):
+
+```bash
+curl -X POST http://localhost:8080/api/admin/users \
+  -H "X-Admin-Key: $ADMIN_API_KEY" \
+  -H 'Content-Type: application/json' \
+  -d '{"display_name":"Oma Anna"}'
+```
+
+**Schritt 3 — mit Token nutzen:**
+
+```bash
+TOKEN=<das-token-von-oben>
+curl http://localhost:8080/api/me -H "Authorization: Bearer $TOKEN"
+
+curl -X POST http://localhost:8080/api/speak \
+  -H "Authorization: Bearer $TOKEN" \
+  -H 'Content-Type: application/json' \
+  -d '{"text":"Guten Morgen!"}'
+```
+
+**Dauerhafte Vorlieben** eines Nutzers (Gerät/Provider/Sprache) setzen:
+
+```bash
+curl -X PUT http://localhost:8080/api/me/prefs \
+  -H "Authorization: Bearer $TOKEN" \
+  -H 'Content-Type: application/json' \
+  -d '{"language":"de","llm_provider":"openrouter"}'
+```
+
+Diese Vorlieben gelten automatisch für alle Aufrufe dieses Nutzers (Ebene zwischen
+Profil und Session). Eine fremde Session zu nutzen, wird mit `403` abgelehnt.
+
+> **Für lokale Entwicklung** ist in der mitgelieferten `.env` `AUTH_ENABLED=false`
+> gesetzt — dann ist kein Token nötig (anonymer Nutzer).
+
+---
+
+## 11. Fehlerbehebung
 
 | Symptom | Ursache | Lösung |
 |---|---|---|
-| `OPENROUTER_API_KEY is empty` / 401 | Key nicht in der Umgebung | `export OPENROUTER_API_KEY=…`, neues Terminal / `source ~/.bashrc` |
+| `OPENROUTER_API_KEY is empty` | Key nicht in der Umgebung | `export OPENROUTER_API_KEY=…`, neues Terminal / `source ~/.bashrc` |
+| HTTP **401** „Bearer token required/Invalid token" | Auth an, Token fehlt/falsch | gültiges Token im Header `Authorization: Bearer …`, oder `AUTH_ENABLED=false` für dev |
+| HTTP **401** bei `/api/admin/users` | falscher/fehlender Admin-Key | `X-Admin-Key` mit `ADMIN_API_KEY` abgleichen |
+| HTTP **403** bei `?session_id=…` | Session gehört anderem Nutzer | eigene `session_id` verwenden |
+| HTTP **503** bei `/api/admin/users` | `ADMIN_API_KEY` nicht gesetzt | Admin-Key in der Umgebung setzen |
 | HTTP **422** „Unbekannter …-Provider/Endpunkt" | Tippfehler in `*_provider` / `*_endpoint` | gültige Werte via `GET /api/config` prüfen |
 | `VA_PROFILE` wirkt nicht | `DEFAULT_*_PROVIDER` in `.env` überschreibt es | diese Zeilen in `.env` auskommentieren |
 | LLM-Timeout / Connection refused (lokal) | lokaler LLM-Server (Port 11434) läuft nicht | LLM-Server starten oder Profil `cloud` wählen |
@@ -213,7 +268,7 @@ Logs erscheinen im Terminal, in dem `make run` läuft. Für mehr Details
 
 ---
 
-## 11. Tests ausführen
+## 12. Tests ausführen
 
 ```bash
 make test