ADR 0002 : vérifie que --unrestricted ne contourne pas l'interdiction des trusts

Testé sur le serveur réel à la demande d'Adam : une application credential
--unrestricted échoue avec la même erreur Keystone que l'application
credential restreinte. Confirme que seule l'authentification par mot de
passe permet à Heat de créer son trust.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/adr/0002-mot-de-passe-pour-heat.md

@@ -41,6 +41,19 @@ temporaire avec `auth_type: password`, `openstack stack create --wait` →
 `CREATE_COMPLETE`. Confirmé avec Adam (choix : « mot de passe classique pour
 `paillasse-service` ») avant d'appliquer en dur.
 
+**Vérifié aussi (2026-10-08, à la question d'Adam) : `--unrestricted` ne
+change rien.** Une application credential créée avec
+`openstack application credential create ... --unrestricted` échoue
+exactement pareil (`heat-engine.log` : même trace, même
+`Forbidden: Delegated tokens cannot manage trusts`, HTTP 403). `--unrestricted`
+lève seulement l'interdiction qu'a une application credential de créer ou
+supprimer *d'autres* application credentials et trusts en tant qu'action
+demandée explicitement par l'appelant — pas l'interdiction, plus profonde,
+qu'a Keystone de délivrer un *nouveau* trust à partir d'un jeton qui est
+lui-même issu d'une délégation. C'est cette seconde règle que Heat déclenche
+(il crée le trust lui-même, côté serveur, pour pouvoir agir plus tard au nom
+de l'appelant) : aucune option d'application credential ne la contourne.
+
 Changements :
 
 - `/etc/kolla/clouds-paillasse.yaml` : `auth_type: password` (mot de passe