Support exporting install configuration as environment variables for stateless deployments

El issue no menciona archivos ni pruebas; empieza rastreando el flujo de instalación, el manejo de AUTO_INSTALL, la carga de config.yaml y la configuración del chart de Helm. Se considerará completado cuando la configuración en tiempo de ejecución pueda exportarse y consumirse mediante variables de entorno documentadas, admita una base de datos externa ya inicializada sin config.yaml, preserve la compatibilidad con versiones anteriores y evite exponer secretos en los logs habituales.

Is your feature request related to a problem? Please describe

Answer's installation flow generates /data/conf/config.yaml, and the Helm chart notes that persistence is required so config.yaml survives restarts. AUTO_INSTALL accepts environment variables for initial setup, but those variables are not used as the runtime configuration afterward.

This makes configuration-stateless container deployments difficult. A pod with a disposable filesystem cannot restart or scale from an already initialized external database using environment variables and secrets alone. Operators must persist or mount the generated config.yaml, or rerun the one-time installer, which is not appropriate once the database has already been initialized.

Describe the solution you'd like

Please allow the install flow to export the effective post-install configuration as a complete, documented set of environment variables, and allow normal Answer startup to consume those variables without requiring config.yaml.

Expected behavior could include:

• An explicit install option or endpoint that exports the effective runtime configuration in a machine-readable environment-variable format, such as dotenv or shell output.
• An environment-variable equivalent for every config.yaml value required at runtime, with documented precedence when both sources are present.
• A fresh Answer instance can connect to an already initialized external database and start using only the exported environment variables, without a local config.yaml.
• Secrets are never printed to ordinary logs; exporting secret-bearing values requires an explicit action and can be directed to a secret manager.
• Existing config.yaml-based deployments remain backward compatible.

This would make Answer easier to run with immutable images, disposable pods, Kubernetes Secrets, and externally managed databases.

Describe alternatives you've considered

• Persist /data/conf on a volume.
• Generate and mount config.yaml from a ConfigMap or Secret.
• Use an init container or entrypoint template to recreate config.yaml on every start.
• Keep using AUTO_INSTALL, although it is a one-time initialization path and fails or becomes inappropriate after the database has already been initialized.