docs(mcp-rollout): align rollout doc with Phase 2 partielle reality

Audit santé du chantier mcp_v1 a montré un écart entre la doc rollout
(advisory only) et l'implémentation réelle (workflows dev-story et
create-story en strict=true, personas dev.md et sm.md avec hard-blocker
sur blocking_issues). Décision : aligner la doc sur l'implem.

Changements :
- rollout_bmad_advisory.md : réécrit pour décrire la Phase 2 partielle
  avec les 3 blocages stricts effectivement actifs (artefacts BMAD seuls,
  sessions sans expiresAt, plan backend sans contracts).
- integration_mcp_sidecar.md : points d'injection mis à jour avec
  strict=true sur dev, advisory sur QA, statut Phase 2.
- mcp_v1.md et README.md : statut 'advisory-first' / 'prototype' →
  'Phase 2 partielle'.
- 40_decisions_et_archi.md : nouvel ADR retraçant le choix.

Note : les customize.yaml invoquent encore strict=false, surchargés par
les workflows. Cohérence interne à traiter dans un prochain commit si
besoin.

40_decisions_et_archi.md

@@ -31,6 +31,7 @@ Dernière mise à jour : 2026-03-12
 - [Single source of truth des contrats — schémas runtime partagés (Zod) + z.infer (No-DTO)](#decision-contrats-sso-zod)
 - [User views — User public par défaut + MeUser explicite](#decision-user-views)
 - [Mono-tenant déployable vs SaaS multi-tenant](#decision-mono-tenant-deployable)
+- [Rollout MCP Lead_tech dans BMAD — Phase 2 partielle (strict ciblé)](#decision-mcp-rollout-phase-2)
 
 ### 2. Infra
 
@@ -336,6 +337,47 @@ Pour un projet dont la cible est constituée de clients indépendants qui veulen
 
 ---
 
+<a id="decision-mcp-rollout-phase-2"></a>
+
+## Rollout MCP Lead_tech dans BMAD — Phase 2 partielle (strict ciblé)
+
+- Date : 2026-05-07
+- Statut : Accepted
+- Périmètre : global / outillage agents
+
+### Contexte
+
+Le serveur `leadtech-bmad-mcp` (sidecar BMAD) a été conçu pour un rollout en 3 phases : Phase 1 advisory only, Phase 2 blocages stricts ciblés, Phase 3 élargissement. À l'origine (`docs/rollout_bmad_advisory.md`), la Phase 1 devait durer 10 à 20 stories pour observer les faux positifs avant toute promotion.
+
+À l'inspection (audit santé du chantier `mcp_v1`), l'implémentation réelle est en avance sur la doc : les workflows BMAD `dev-story` et `create-story` appellent les tools en `strict=true`, et les personas `dev.md` et `sm.md` traitent `blocking_issues` comme hard blockers nécessitant override humain. La doc rollout disait l'inverse.
+
+### Options envisagées
+
+- **Aligner l'implémentation sur la doc** : revert workflows à `strict=false`, retirer les HALT des personas. Reste en pure Phase 1.
+- **Aligner la doc sur l'implémentation** : déclarer Phase 2 partielle, lister précisément les blocages stricts actifs, et garder le reste en advisory.
+- **Voie médiane** : créer une Phase 1.5 transitoire avec critères chiffrés de promotion.
+
+### Décision
+
+Aligner la doc sur l'implémentation : **déclarer Phase 2 partielle** avec 3 blocages stricts actifs et le reste en advisory.
+
+### Justification
+
+- Les 3 blocages effectivement actifs (artefacts BMAD seuls, sessions sans expiresAt, plan backend sans contracts) sont **précisément les 3 candidats Phase 3 de la doc d'origine** — donc le saut Phase 1 → Phase 2 reflète une décision de fond cohérente.
+- Le signal de ces 3 règles est fort et la formulation textuelle est faiblement ambiguë.
+- Override humain explicite préservé sur tout `blocking_issues`, donc pas de blocage rigide.
+- Coût d'observation Phase 1 considéré comme dépensable a posteriori sur les 10-20 prochaines stories.
+
+### Conséquences
+
+- `docs/rollout_bmad_advisory.md` reflète la Phase 2 partielle et liste les 3 blocages actifs avec leurs sources (hardcode `server.py` + `gates.yaml`).
+- `80_bmad/integration_mcp_sidecar.md` aligné sur le même statut.
+- Statut `mcp_v1.md` et `mcp/leadtech_bmad_mcp/README.md` ajustés.
+- Incohérence interne résiduelle à traiter : les `_config/agents/*.customize.yaml` invoquent encore `strict=false`, surchargés par les workflows en `strict=true`. À aligner si besoin de cohérence stricte.
+- Observabilité Phase 2 : suivi du nombre de blocages, faux positifs, overrides humains sur les 10-20 prochaines stories avant éventuelle Phase 3.
+
+---
+
 ## 2. Infra
 
 <a id="decision-structure-docker"></a>