docs: acte la terminaison TLS par l'ADR 0007 et met à jour les vues

L'ADR 0007 tranche le reverse proxy en Compose plutôt que l'ingress k3s, qui
supposait un registre et des manifestes inexistants, et referme la première
question ouverte de 10-infra.md.

Les vues suivent : troisième topologie et ports 80/443 dans 10-infra.md, TLS,
HSTS et CSP passent d'« Absent, et assumé » à « En place » dans la vue
d'ensemble, la ligne API8 transport rejoint les points couverts de la
traçabilité OWASP.

Trois affirmations périmées disparaissent au passage : le compose a bien un
service frontend, environment.ts ne pointe plus sur localhost:8000, et le
Dockerfile du front n'est plus mono-étage sur une branche.

docs/architecture/30-frontend.md

@@ -97,11 +97,11 @@ En développement, `proxy.conf.json` redirige tout `/api` vers `http://localhost
 qui évite le CORS sur le poste, et c'est pourquoi `environment.development.ts` se contente d'un
 `apiUrl` relatif, `/api/v1`.
 
-En production, il n'y a pas de proxy, mais `environment.ts` porte lui aussi un `apiUrl` relatif
-(`/api/v1`) plutôt qu'une URL absolue : la dette qui pointait en dur sur
-`http://localhost:8000/api/v1` a été corrigée. Un build de production sert donc l'appel `/api/v1/...`
-sur son propre origin, ce qui suppose qu'un ingress ou un reverse proxy route `/api` vers le
-backend une fois déployé — question toujours ouverte dans [10-infra.md](10-infra.md).
+En production, `environment.ts` porte lui aussi un `apiUrl` relatif (`/api/v1`) plutôt qu'une URL
+absolue : la dette qui pointait en dur sur `http://localhost:8000/api/v1` a été corrigée. Un build
+de production sert donc l'appel `/api/v1/...` sur son propre origin, et c'est le **reverse proxy**
+qui route `/api` vers le backend : `location /api/` dans `infra/proxy/conf.d/enervision.conf`, voir
+[10-infra.md](10-infra.md) et l'[ADR 0007](../adr/0007-terminaison-tls-et-reverse-proxy-nginx.md).
 
 ## Exécution
 
@@ -118,13 +118,14 @@ le message d'erreur arrive avant toute compilation. Un poste en 22.21 ou en 24.1
 tester ni construire le frontend.
 
 Le frontend a ses cibles dans le `Makefile` racine (`install-frontend`, `dev-frontend`,
-englobées par `install` et `dev`), mais **aucun service dans `docker-compose.yml`** : en
-développement il tourne toujours directement via `npm`, depuis `apps/frontend`. Le port 4200
-n'apparaît dans le compose que comme valeur par défaut d'`APP_CORS_ORIGINS`, côté backend.
+englobées par `install` et `dev`). En développement il tourne directement via `npm`, depuis
+`apps/frontend` : le port 4200 n'apparaît dans le compose que comme valeur par défaut
+d'`APP_CORS_ORIGINS`, côté backend.
 
-Un `Dockerfile` frontend existe sur la branche `feat/pipeline-cd`, mais il est mono-étage et sans
-`CMD` : il construit sans rien servir. Le `README.md` de l'application demande un multi-étage
-avec un service statique, il reste à écrire.
+Le service `frontend` du `docker-compose.yml` sert le build statique par le nginx de
+`apps/frontend/Dockerfile`, multi-étage, qui **écoute sur 3000**. En déploiement il n'est plus
+publié du tout : le reverse proxy est seul à sortir sur le réseau, et l'atteint par le réseau
+Compose.
 
 ## Sécurité