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

docs/ai-excellence-due-diligence-roadmap.md

@@ -11,7 +11,7 @@ At the same time, the codebase still carries several risks that are typical of f
 
 1. some critical cross-cutting concerns are only partially productized
 2. several files and routers have grown beyond comfortable ownership size
-3. runtime configuration and secret handling are still too application-database centric
+3. runtime secret handling is now materially cleaner, but the repo still needs to standardize the operational source of truth around that model
 4. the current operational model is improving, but not yet fully standardized
 5. production-grade multi-instance safeguards are not complete yet
 
@@ -47,10 +47,10 @@ The previously critical SSE and browser parser coverage issues were addressed du
    Evidence: [assistant-tools.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/assistant-tools.ts), [resource.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/resource.ts), [allocation.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/allocation.ts), [timeline.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/timeline.ts), [vacation.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/vacation.ts), and large frontend files such as [SystemSettingsClient.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/admin/SystemSettingsClient.tsx) and [TimelineProjectPanel.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/timeline/TimelineProjectPanel.tsx) are each well past the size where safe ownership stays easy.
    Risk: AI-generated changes become harder to review, humans lose local reasoning context, and regressions become more likely.
 
-2. Secret handling is still application-database centric.
-   Evidence: system settings mutate and persist API keys and SMTP credentials in [settings.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/settings.ts).
-   Risk: operational secrets remain too coupled to the main app data plane for a gold-standard project.
-   Update: runtime resolution is now env-first for the active secret consumers, but persistence is still transitional and should be reduced further.
+2. Runtime secret policy is mostly corrected, but deploy standardization still has to catch up.
+   Evidence: runtime resolution and admin flows now treat environment-backed secrets as the preferred source in [settings.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/settings.ts), [system-settings-runtime.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/lib/system-settings-runtime.ts), and [SystemSettingsClient.tsx](/home/hartmut/Documents/Copilot/capakraken/apps/web/src/components/admin/SystemSettingsClient.tsx).
+   Risk: a strong secret policy is only fully effective once staging and production provisioning use one canonical deployment path and operators clear remaining legacy database copies.
+   Update: the application no longer persists new operational secret values through admin settings; the remaining work is rollout discipline and cleanup completion.
 
 3. Least-privilege is materially better documented now, but it still needs long-lived enforcement rather than relying mainly on one hardening batch.
    Evidence: the route audience model is now explicit in [route-access-matrix.md](/home/hartmut/Documents/Copilot/capakraken/docs/route-access-matrix.md) and backed by multiple focused auth tests, but the remaining guarantee still depends on continuing test coverage and architecture guardrails as new routes evolve.
@@ -80,9 +80,9 @@ This is materially better than a typical startup CRUD app and already has the bo
 
 ### Security Posture
 
-`7/10`
+`7.5/10`
 
-There are good foundations, and the most obvious real-time and comment-visibility gaps were closed, but secrets policy and long-lived least-privilege enforcement still need structural work.
+There are good foundations, and the most obvious real-time, comment-visibility, and runtime-secret-policy gaps were closed, but long-lived least-privilege enforcement and operational standardization still need structural work.
 
 ### Maintainability
 
@@ -124,8 +124,8 @@ Goals:
 - Keep SSE audience scoping under test and CI guardrails.
 - Keep hardened spreadsheet parser boundaries under regression coverage.
 - Treat the route access matrix and narrowed auth slices as maintained architecture contracts.
-- Move production secrets out of regular application settings, or add an interim encrypted-secrets layer with clear migration path.
-  Status: in progress. Runtime consumers now prefer environment overrides; the remaining gap is eliminating or encrypting compatibility persistence in the admin settings path.
+- Enforce the environment-only runtime secret policy operationally and clear remaining legacy database secret residue.
+  Status: mostly completed in code. Runtime consumers prefer environment values, admin updates no longer store new secret material, and operators now need to finish rollout/bootstrap documentation plus cleanup of old database copies.
 
 Definition of done:
 
@@ -222,12 +222,11 @@ Artifacts to add:
 
 ## Suggested Order Of Execution
 
-1. secrets policy
-2. router/component decomposition
-3. architecture fitness checks in CI
-4. full operational standardization
-5. production-grade rate limiting
-6. performance hotspot reduction
+1. router/component decomposition
+2. architecture fitness checks in CI
+3. full operational standardization
+4. production-grade rate limiting
+5. performance hotspot reduction
 
 ## Success Criteria For The Next 60 Days