[Feature]: `{{ env }}` / `{{ file }}` interpolation in `config.toml` across API Platform

[thivindu]

Please select the area the issue is related to

Gateway, Platform API, Developer Portal, AI Workspace

Please select the aspect the issue is related to

Aspect/Configuration (Config files, settings, env vars, defaults)

Suggested Feature

Problem

The API Platform Gateway, Platform API and AI Workspace, loads config.toml via Koanf, but operators have no clean way to inject values — especially secrets - into individual config fields. APIP_* environment overrides cannot index into [[array-of-tables]] elements (e.g. [[controller.auth.basic.users]], [[controller.encryption.providers.keys]]), and committing secrets to Helm values.yaml (Git) is unacceptable while plain environment variables leak via /proc/<pid>/environ, kubectl describe, and crash dumps.

Proposed Solution

Implement Go text/template interpolation to config.toml, standardizing on the same {{ ... }} syntax already used for REST API spec templating, so values can be sourced from environment variables or mounted secret files at startup.

Discussion: #2592

Goals

• Let operators interpolate any config.toml field, including array-of-tables elements, with {{ env "NAME" ["default"] }} and {{ file "/path" }}.
• Provide a fail-closed, secret-safe path for injecting credentials (prefer mounted files over environment variables).
• Keep the mechanism shared across different components across the API Platform without touching the existing REST API spec template engine.
• Remain fully backward compatible — the existing APIP_* Koanf env resolution is unchanged.

User stories

• As an operator, I want to inject a gateway registration token or basic-auth password from a mounted Kubernetes Secret file so credentials never appear in Git or environment variables.
• As an operator, I want the related component to refuse to start when a required secret is missing, rather than boot with an empty value.

Related Issues

#2593, #2591, #2592

Steps to Verify

• Design Document — A detailed design document has been created and reviewed, covering architecture, data flow, and edge cases.
• Design Mail — A design summary email has been sent to relevant stakeholders for awareness and feedback.
• Code Review — All code changes have been peer-reviewed and approved according to the project's review standards.
• Testing Complete — Adequate unit, integration, and/or end-to-end tests have been written and are passing.
• Documentation Review — User-facing and/or developer documentation has been updated to reflect the new feature and reviewed.
• Feature Complete — The feature is fully implemented, all checklist items above are done, and it is ready for release.