fix(platform): make the data-residency settings do what the docs promise

docs/de/self-hosted/configuration/environment-reference.md

@@ -59,7 +59,7 @@ Tale hält zwei Datenbanken: den operativen Speicher (`tale_app` — Agents, Run
 | `KNOWLEDGE_INDEX_REPAIR_INLINE_MAX_BYTES` | `1073741824`                                                        | **Optional.** Größter BM25-Suchindex (in Bytes), den das Backend beim Start synchron neu aufbaut, wenn es ihn beschädigt vorfindet; einen größeren baut ein Hintergrundjob neu auf, während Schreibzugriffe auf diesen Korpus abgewiesen werden. Siehe [Container-Architektur](/de/self-hosted/operate/container-architecture). |
 | `KNOWLEDGE_INDEX_REPAIR_DISABLED`         | nicht gesetzt                                                       | **Optional.** `1` oder `true` schaltet die Prüfung und Reparatur der BM25-Suchindizes beim Start ab. Ein beschädigter Index bringt die Wissensdatenbank dann bei jedem Schreibzugriff zum Absturz, bis er von Hand neu aufgebaut wird.                                                                                          |
 
-Die auto-konstruierte operative Form ist `postgresql://tale:${DB_PASSWORD}@db:5432` — ohne Datenbanknamen; die operative Datenbank wird aus der Instanz-Konfiguration abgeleitet. Das Application-Backend speichert seine Daten in der `tale_app`-Datenbank auf demselben Server (überschreib den Namen mit `APP_DB_NAME`). Der Wissens-Korpus lebt in `tale_knowledge` mit den Schemata `private_knowledge` und `public_web`; die UI unter **Einstellungen > Datenresidenz** schreibt eine reichere Per-Store-Konfiguration als diese rohen Variablen, behandelt in [Datenresidenz](/de/self-hosted/configuration/data-residency).
+Die auto-konstruierte operative Form ist `postgresql://tale:${DB_PASSWORD}@db:5432` — ohne Datenbanknamen; die operative Datenbank wird aus der Instanz-Konfiguration abgeleitet. Das Application-Backend speichert seine Daten in der `tale_app`-Datenbank auf demselben Server (überschreib den Namen mit `APP_DB_NAME`). Der Wissens-Korpus lebt in `tale_knowledge` mit den Schemata `private_knowledge` und `public_web`; diese Variablen setzen die Deployment-Defaults, die alle Organisationen teilen; eine Organisation kann zusätzlich ihren eigenen Korpus und ihren eigenen Bucket unter **Einstellungen > Datenresidenz** auf eigene Infrastruktur richten (Dateien pro Organisation, live wirksam, kein Neustart), behandelt in [Datenresidenz](/de/self-hosted/configuration/data-residency).
 
 ## Object-Store
 
@@ -161,7 +161,7 @@ Optionale Schalter für Features, die standardmässig nicht aktiviert sind. Jede
 | `TRUSTED_ROLE_HEADER`             | `Remote-Role`            | Name des Request-Headers mit der Organisationsrolle, mit der die Session handelt (`member`, wenn der Header fehlt).                                                                                                                          |
 | `TRUSTED_TEAMS_HEADER`            | `Remote-Teams`           | Name des Request-Headers mit den Team-Zugehörigkeiten als kommagetrennte `id:name`-Einträge. Fehlt er, bleiben Teams unangetastet; ist er gesetzt, gilt die Liste des Proxys für die von ihm vergebenen Zugehörigkeiten (leer entzieht sie). |
 | `TALE_FILE_EVENTS`                | `false`                  | Streamt Änderungen an Config-Dateien unter `TALE_CONFIG_DIR` an offene Browser-Tabs (`/events/file`): Eine auf der Platte bearbeitete Agent-, Skill- oder Branding-Datei erscheint ohne Reload. Im Dev-Compose an, in Produktion aus.        |
-| `TALE_DEPLOYMENT_CONFIG_ADMINS`   | unset                    | Kommagetrennte E-Mail-Allowlist der Operatoren, die die Datenresidenz bearbeiten dürfen. Leer/nicht gesetzt = nur lesend für alle Admins.                                                                                                    |
+| `TALE_DEPLOYMENT_CONFIG_ADMINS`   | unset                    | Kommagetrennte E-Mail-Allowlist der Operatoren, die die Deployment-Konfigurationsdatei (`deployment.yml`, heute der Abschnitt zur Sandbox-Runtime) über die API schreiben dürfen. Leer/nicht gesetzt = nur lesend für alle Admins. Die Datenresidenz wird pro Organisation konfiguriert und hängt nicht an dieser Liste. |
 
 ## RAG-Retrieval-Tuning
 

docs/de/self-hosted/configuration/video-ingestion.md

@@ -47,7 +47,7 @@ curl -sS -X POST "https://your-host.example.com/api/v1/browser-sessions/import"
 # → 201 { "sessionId": "..." }
 ```
 
-Der Import ist der heikelste Schreibzugriff der Bereitstellung und deshalb doppelt abgesichert: Der Schlüssel muss einem Administrator der Organisation gehören, und dessen E-Mail-Adresse muss auf der Allowlist `TALE_DEPLOYMENT_CONFIG_ADMINS` stehen — derselben Liste, die die [Datenresidenz](/de/self-hosted/configuration/data-residency) schützt. Alle anderen bekommen **403** mit einem `code`, der die verweigernde Hürde nennt. Gehört der Nutzer des Schlüssels mehreren Organisationen an, musst du mit `X-Organization-Slug` sagen, in welche importiert wird — ohne den Header antwortet der Schreibzugriff mit **400**; bei nur einer Mitgliedschaft kannst du den Header weglassen. `GET /api/v1/browser-sessions` listet den Pool mit Status, Ablauf und Fehlschlagzähler jeder Session — nie die Cookies selbst. Eine Session lebt 14 Tage, sofern `ttlMs` nichts anderes sagt, und nur das Einlesen von Videolinks schöpft aus dem Pool.
+Der Import ist der heikelste Schreibzugriff der Bereitstellung und deshalb doppelt abgesichert: Der Schlüssel muss einem Administrator der Organisation gehören, und dessen E-Mail-Adresse muss auf der Allowlist `TALE_DEPLOYMENT_CONFIG_ADMINS` stehen — derselben Liste, die Schreibzugriffe auf die Deployment-Konfigurationsdatei (`deployment.yml`) absichert, beschrieben in der [Umgebungsreferenz](/de/self-hosted/configuration/environment-reference). Alle anderen bekommen **403** mit einem `code`, der die verweigernde Hürde nennt. Gehört der Nutzer des Schlüssels mehreren Organisationen an, musst du mit `X-Organization-Slug` sagen, in welche importiert wird — ohne den Header antwortet der Schreibzugriff mit **400**; bei nur einer Mitgliedschaft kannst du den Header weglassen. `GET /api/v1/browser-sessions` listet den Pool mit Status, Ablauf und Fehlschlagzähler jeder Session — nie die Cookies selbst. Eine Session lebt 14 Tage, sofern `ttlMs` nichts anderes sagt, und nur das Einlesen von Videolinks schöpft aus dem Pool.
 
 <Warning>