fix(backend): inject provider credentials from file

docs/general/pi-configuration.md

@@ -2,6 +2,16 @@
 
 Pi (il coding agent che orchestra il workflow NL→SQL) può risolvere un `provider/model` in tre modi diversi. Non sono alternativi: coesistono, e la scelta di quale usare dipende da **quanto è standard l'endpoint** e da **quanto deve essere ampia la visibilità** del modello (tutti i progetti vs. un progetto solo).
 
+## Credenziali nel backend container
+
+In produzione configurare una sola sorgente generica, `THT_MODEL_API_KEY_FILE`, come secret file
+assoluto e non il valore della chiave. `PiProcessManager` rilegge e valida il file per ogni processo,
+normalizza il provider selezionato e passa al solo child Pi la variabile nativa appropriata
+(`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`, `ZAI_API_KEY`, ecc.). Il percorso generico,
+le chiavi di provider non selezionati e il vecchio `PI_PROVIDER_API_KEY` vengono rimossi dall'ambiente
+del child. Provider locali come `ollama`, `lmstudio` e `aritmolab` continuano senza chiave; un provider
+hosted non mappato o un secret mancante/non sicuro fallisce prima dello spawn con errore sanitizzato.
+
 ## I tre livelli di provenienza di un modello
 
 ### 1. Built-in (compilato dentro Pi)