fix(deploy): passe de DuckDNS à deSEC, filtré par l'école

Le filtrage du réseau de l'école bloque duckdns.org, site et API, depuis
les postes comme depuis la VM : sans API, pas de défi DNS-01. deSEC
(dedyn.io) répond depuis les deux.

- Domaine enervision-g3.dedyn.io ; provision-host.sh publie par l'API
  deSEC l'enregistrement du domaine et son joker vers la VM.
- make tls-desec remplace tls-duckdns. acme.sh recopie le jeton dans
  acme/account.conf : le dossier est retiré aux autres comptes.
- deploy.yml ne demande un certificat qu'à un .env déjà réaligné sur
  le domaine deSEC, pour ne pas faire échouer un déploiement en cours
  de migration.

docs/architecture/10-infra.md

@@ -238,7 +238,7 @@ Deux conséquences se propagent jusqu'à l'application, et elles ne se devinent
 Statut : `En cours`. Décision et motifs dans
 l'[ADR 0009](../adr/0009-deux-environnements-compose-sur-la-vm-eni.md), étendue à un troisième
 environnement par l'[ADR 0017](../adr/0017-environnement-dev-a-la-demande.md) ; noms,
-certificats et frontal sans port dans l'[ADR 0018](../adr/0018-noms-duckdns-certificats-dns01-et-frontal-sni.md).
+certificats et frontal sans port dans l'[ADR 0018](../adr/0018-noms-desec-certificats-dns01-et-frontal-sni.md).
 La VM `eadl-2025-nantes-g3` porte le développement, la recette et la production, chacun dans son
 clone du dépôt, son `.env` et son projet Compose. Le nom de projet préfixe volumes, réseau et
 conteneurs : rien n'est partagé. `scripts/provision-host.sh` prépare les trois dossiers, génère
@@ -248,20 +248,20 @@ les secrets et les certificats, et ne démarre rien.
 |---|---|---|---|
 | Branche, environnement GitHub | toute branche lancée à la main, `dev` | `dev`, `rec` | `main`, `prod` |
 | Dossier, projet Compose | `/srv/enervision/dev`, `enervision-dev` | `/srv/enervision/rec`, `enervision-rec` | `/srv/enervision/prod`, `enervision-prod` |
-| URL | `https://dev.enervision-g3.duckdns.org` | `https://rec.enervision-g3.duckdns.org` | `https://enervision-g3.duckdns.org` |
+| URL | `https://dev.enervision-g3.dedyn.io` | `https://rec.enervision-g3.dedyn.io` | `https://enervision-g3.dedyn.io` |
 | Proxy HTTP, HTTPS, PROXY protocol, sur `127.0.0.1` | `8083`, `9443`, `9444` | `8081`, `8443`, `8444` | `10080`, `10443`, `10444` |
 | PostgreSQL, Mailpit, Airflow, sur `127.0.0.1` | `5435`, `8027`, `8084` | `5434`, `8026`, `8082` | `5433`, `8025`, `8080` |
 | Supervision (profil `monitoring`) | à la demande, `make monitoring-up` | à la demande, `make monitoring-up` | active, `COMPOSE_PROFILES=monitoring` |
 | Grafana, Prometheus, Alertmanager, sur `127.0.0.1` | `3003`, `9092`, `9095` | `3002`, `9091`, `9094` | `3001`, `9090`, `9093` |
 
-Les trois noms sont publics chez DuckDNS et visent l'IP privée de la VM : rien à déclarer sur
+Les trois noms sont publics chez deSEC et visent l'IP privée de la VM : rien à déclarer sur
 les postes du réseau de l'école, et rien n'est joignable hors de ce réseau. Trois noms distincts
 sont nécessaires : le cookie `__Secure-ev_refresh` est posé par hôte, pas par port.
 
 Aucune stack ne publie hors de la boucle locale. Le frontal `infra/front`, sur le réseau de
 l'hôte, écoute 80 et 443 : il redirige le premier, et aiguille le second d'après le nom demandé
 (SNI) vers l'écouteur PROXY protocol de la stack visée, sans déchiffrer le TLS. Chaque stack
-garde son certificat Let's Encrypt, obtenu par défi DNS-01 (`make tls-duckdns`) et renouvelé à
+garde son certificat Let's Encrypt, obtenu par défi DNS-01 (`make tls-desec`) et renouvelé à
 chaque déploiement ainsi que chaque nuit par `/etc/cron.d/enervision-tls`.
 
 Le déploiement est décrit dans [50-cicd.md](50-cicd.md) : un runner GitHub Actions installé sur