docs: ajoute section Yesmine-Key (allowed_models mimo-v2.5, retrait deepseek) au runbook migration mimo

common/migration-mimo-v25-cerveau-hermes.md

@@ -94,3 +94,51 @@ sans erreur de limite cote opencode-go/Bifrost au premier essai.
 
 `hermes-nyora/verdict-pilote-mimo-v25.md`, `hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md`,
 `common/bifrost-access.md`, `common/bifrost-vk-incidents.md`, `common/opencode-go-migration.md`.
+
+
+## Yesmine-Key (VK Bifrost, hermes-desktop-yesmine — client pas encore actif)
+
+**Perimetre** : uniquement la VK Bifrost `Yesmine-Key` (id `028c7103-cc9f-4139-96a1-3d5420b2d2dd`).
+Aucune instance NAS ni fichier agent — toute la config vit en DB Bifrost
+(`governance_virtual_key_provider_configs`).
+
+**Etat trouve (Phase 1, verifie en live, rien suppose)** :
+- `allowed_models` (provider `opencode`, row id=38) = `["deepseek-v4-flash"]` uniquement —
+  mimo-v2.5 absent malgre une decision anterieure supposee (audit du 17/08). `allow_all_keys`
+  deja a 1 (pas de correction necessaire la-dessus).
+- Aucun concept de "modele par defaut" par VK cote Bifrost : schema `governance_virtual_keys`
+  n'a pas de champ modele ; `routing_rules`/`routing_targets` ne referencent aucun `virtual_key_id`
+  scope sur Yesmine-Key. Seul filtre existant = `allowed_models`. Le seul enregistrement scope
+  sur cette VK dans `governance_model_configs` est un rate-limit generique (`model_name='*'`), pas
+  un modele par defaut.
+- Pas de concept context_length/max_output au niveau VK — ces valeurs sont globales par modele
+  (`governance_model_pricing`), deja documente vide pour `mimo-v2.5/opencode-go` plus haut dans ce
+  runbook. Hors perimetre de corriger cette table globale ici (deja couverte par les valeurs en dur
+  1048576/131000 appliquees sur les yaml de la flotte ; Bifrost lui-meme ne bloque pas sur cette
+  table vide, confirme par le test Phase 3 ci-dessous).
+
+**Correction appliquee (Phase 2, edition DB directe — PAS l'API governance, piege `allow_all_keys`
+reset connu)** :
+```sql
+UPDATE governance_virtual_key_provider_configs
+SET allowed_models = '["mimo-v2.5"]'
+WHERE id = 38 AND virtual_key_id = '028c7103-cc9f-4139-96a1-3d5420b2d2dd' AND provider = 'opencode';
+```
+`docker restart bifrost` obligatoire (chargement DB au boot, memoire vive garde l'ancien etat sinon)
+— confirme healthy apres ~50s.
+
+**Test Phase 3 (controle minimal, hors tool-calling — pas de client reel a simuler)** :
+- Appel direct `x-bf-vk` vers `mimo-v2.5` : `resolved_model_used: mimo-v2.5`, `finish_reason: stop`,
+  aucune erreur.
+- Verification du retrait reel (pas juste un ajout) : appel `deepseek-v4-flash` sur la meme VK →
+  rejete (`could not auto resolve a provider for the request`) — confirme que le retrait est effectif,
+  pas seulement documentaire.
+
+**Trace** : ce changement n'existe qu'en DB Bifrost (`config.db`, table
+`governance_virtual_key_provider_configs`), aucun fichier Git associe — pas de repo pour cette
+config, contrairement aux instances Hermes. Cette entree de runbook est la seule trace ecrite du
+changement, a ne pas oublier lors d'une future migration modele generale sur Bifrost.
+
+**Point ouvert** : `Yesmine-Key` reste provisionnee sans consommateur actif — aucun agent/client
+n'appelle cette cle aujourd'hui (`hermes-desktop-yesmine` n'existe pas encore cote Windows/Claude
+Desktop). A reevaluer (usage reel, cout, modele par defaut souhaite) quand ce client devient actif.