refactor(settings): adopt environment-only runtime secret flow

docs/cicd-target-architecture.md

@@ -30,6 +30,7 @@ That removes "works on the server but not in CI" drift and makes rollbacks much
 
 The existing `CI` workflow continues to validate:
 
+- architecture guardrails for SSE audience scoping
 - typecheck
 - lint
 - unit tests
@@ -38,6 +39,12 @@ The existing `CI` workflow continues to validate:
 
 This remains the quality gate before merge.
 
+The guardrail step currently enforces three invariants:
+
+- no role-based SSE audience fan-out in [event-bus.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/sse/event-bus.ts)
+- no role-derived subscription audiences in [subscription-policy.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/sse/subscription-policy.ts)
+- no client-provided audience parsing in [route.ts](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/app/api/sse/timeline/route.ts)
+
 ### 2. Image Build
 
 The new manual workflow [release-image.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/release-image.yml) builds two images from [Dockerfile.prod](/home/hartmut/Documents/Copilot/capakraken/Dockerfile.prod):
@@ -149,6 +156,28 @@ NEXTAUTH_SECRET=<long-random-secret>
 
 GitHub Actions only injects the short-lived image references through `deploy.env`. The deploy script then loads both files before calling Docker Compose, so compose interpolation and container runtime env use the same source of truth.
 
+### Runtime Secret Provisioning Policy
+
+Production and staging secrets should be provisioned at the host or platform-secret layer, not through admin mutations and not through application database writes.
+
+That includes at least:
+
+```env
+OPENAI_API_KEY=<optional-if-openai-used>
+AZURE_OPENAI_API_KEY=<optional-if-azure-chat-used>
+AZURE_DALLE_API_KEY=<optional-if-azure-image-gen-used>
+GEMINI_API_KEY=<optional-if-gemini-used>
+SMTP_PASSWORD=<required-if-smtp-auth-used>
+ANONYMIZATION_SEED=<required-if-deterministic-anonymization-enabled>
+```
+
+Operational rule:
+
+- keep these values in `.env.production` only for smaller self-managed hosts, or preferably in the host's secret manager / encrypted environment facility
+- do not rotate or patch these values through `SystemSettings`
+- use the admin settings page only to verify runtime source/status and to clear leftover legacy database copies
+- after migration, legacy database secret fields should be empty in both staging and production
+
 ## Database Policy
 
 For release environments, use:
@@ -183,6 +212,8 @@ The intended production update path is:
 
 That means the production host no longer builds from Git. It only receives a versioned image and starts it after migrations complete.
 
+The same principle applies to secrets: the running container reads them from the deployment environment at start time, so an update only needs a new image tag unless secret material itself is being rotated.
+
 ## Current Status
 
 The repository now contains the CI/CD scaffolding, but the existing manual production setup remains untouched: