Kanbante 0.46.5 — pont draco : adoption de l'amorçage conditionnée (fusion #145) et échec de connexion suggérant le SSO (fusion #144)

docs/correspondance-draco.md

@@ -36,16 +36,32 @@ Dans l'ordre :
 2. **Correspondance existante** : la session du compte lié est
    ouverte. Un compte **désactivé** n'ouvre aucune session et
    n'est jamais contourné (voir § Désactivation).
-3. **Compte d'amorçage** : s'il n'existe qu'**un seul compte** et
-   que c'est un **admin actif sans liaison**, le premier `sub`
-   valide s'y lie et sa session est ouverte. C'est le cas du
-   compte créé à l'installation depuis l'environnement
-   (`KANBANTE_AUTH_USER` / `KANBANTE_AUTH_PASSWORD`, Bruno) : sa
-   correspondance s'établit au premier passage, sans le verrouiller
-   dehors. Ses autres accès restent inchangés dans tous les cas :
-   connexion native avec le mot de passe du compte, et repli
-   d'urgence par les identifiants d'environnement (formulaire et
-   Basic), qui ne dépendent pas de draco.
+3. **Compte d'amorçage — adoption conditionnée (fusion #145,
+   0.46.5)** : s'il n'existe qu'**un seul compte** et que c'est un
+   **admin actif sans liaison**, ce compte (celui créé à
+   l'installation depuis l'environnement `KANBANTE_AUTH_USER` /
+   `KANBANTE_AUTH_PASSWORD`, Bruno) n'est adopté que dans l'un
+   de ces deux cas :
+   - **(a)** le `sub` entrant est **« administrateur » pour
+     kanbante au registre des rôles du Hub** (le pont consulte le
+     registre avant la résolution et transmet le rôle à
+     `resolve_draco_user()` ; Hub muet ou rôle moindre = **pas
+     d'adoption**, dans le doute on ne lie pas) ;
+   - **(b)** l'adoption est initiée depuis une **session native
+     déjà authentifiée** (point 1 ci-dessus, ou connexion native
+     doublement connectée) : l'utilisateur connecté lie
+     explicitement son propre compte.
+   Tout autre `sub` inconnu reçoit le parcours ordinaire
+   (création JIT d'un compte **membre** propre, point 4) —
+   jamais l'amorçage. Avant la 0.46.5, le premier `sub` valide
+   de passage adoptait l'amorçage quel qu'il soit : sur une
+   instance fraîche, un simple utilisateur de la suite devenait
+   l'administrateur local (audit « compte partout » du
+   2026-11-06). Les autres accès de l'amorçage restent inchangés
+   dans tous les cas : connexion native avec le mot de passe du
+   compte, et repli d'urgence par les identifiants
+   d'environnement (formulaire et Basic), qui ne dépendent pas
+   de draco.
 4. **Création JIT** : sinon, un compte Kanbante est créé pour
    cette identité (détail ci-dessous) et sa session est ouverte.
 
@@ -139,11 +155,13 @@ internes ni la réconciliation par étiquettes ne changent.
 
 - **`GET /api/search`** (« Rechercher partout ») : le cookie draco
   n'y est plus accepté « en tant qu'opérateur ». Il faut que le
-  `sub` désigne un compte (correspondance existante ou compte
-  d'amorçage lié au passage). Aucune création JIT sur cette
-  surface : la création a lieu à la première vraie connexion, par
-  le pont. Les autres modes d'accès à `/api/search` (session,
-  Basic, jeton `kbt_`) sont inchangés.
+  `sub` désigne un compte (correspondance existante). Cette
+  surface ne consulte pas le registre et n'initie aucune liaison :
+  elle ne peut donc **jamais adopter le compte d'amorçage**
+  (fusion #145) — l'adoption a lieu au pont, ou pas. Aucune
+  création JIT sur cette surface : la création a lieu à la
+  première vraie connexion, par le pont. Les autres modes d'accès
+  à `/api/search` (session, Basic, jeton `kbt_`) sont inchangés.
 - **Désactivation** : désactiver un compte dans `/admin` coupe
   tous ses accès — session native, pont draco (la correspondance
   résout à « refusé ») et jetons `kbt_`. Réactiver le compte