fix(infra,ci): aligne le provisionnement et le déploiement sur Airflow 3

La migration Airflow 3 est arrivée sur `dev` après l'écriture du chemin de
déploiement, qui en a gardé quatre traces fausses, invisibles en CI puisque
aucun job ne joue ce chemin.

`provision-host.sh` substituait `AIRFLOW_WEBSERVER_SECRET_KEY`, clé disparue.
`AIRFLOW_API_SECRET_KEY` et `AIRFLOW_JWT_SECRET` restaient donc à `change_me`
dans le `.env` posé sur la machine, et le `:?` d'`airflow-init` ne voit pas
une valeur d'exemple : la stack aurait démarré avec un secret de session et un
secret JWT prévisibles. Le `.env` est maintenant écrit après contrôle, et le
script refuse de le poser s'il reste un `change_me` hors `APP_MOCK_API_*`.

`make services-up` démarrait `airflow-webserver`, service supprimé par la
migration ; seul `airflow-up` avait été aligné.

L'overlay posait `AIRFLOW__WEBSERVER__WORKERS`, sans effet en Airflow 3 où la
section est `[api]`. Le réglage disparaît plutôt que d'être renommé : le défaut
y vaut un worker, moins que les deux qu'on visait.

Le diagnostic d'échec de `deploy.yml` lisait les journaux sans l'overlay, donc
sans service `proxy` : il échouait avant d'imprimer quoi que ce soit.

.env.example

@@ -70,7 +70,7 @@ PUBLIC_ORIGIN=
 PROXY_HTTP_PORT=
 PROXY_HTTPS_PORT=
 # Réglages mémoire de la stack déployée. Sans eux, timescaledb-tune réserve 25 % de la RAM de la
-# machine à chaque base au premier démarrage, et le webserver Airflow lance 4 workers gunicorn.
+# machine à chaque base au premier démarrage. L'api-server Airflow 3 n'a rien à régler ici : son
+# nombre de workers vaut 1 par défaut, contre 4 pour le webserver d'Airflow 2.
 TS_TUNE_MEMORY=2GB
 TS_TUNE_NUM_CPUS=2
-AIRFLOW_WEBSERVER_WORKERS=2