docs(specs) : documente GET /users/{id}/rbac et garde anti-ecrasement merge-patch

Ajoute les sections "Evolutions post-livraison" aux specs Sites #02 et RBAC #345
pour refleter les modifs apportees apres la livraison initiale :

- GET /users/{id}/rbac symetrique au PATCH, pour charger le detail d'edition
  sans elargir le groupe user:list (le payload de liste reste leger, la
  dependance Core → Sites reste scopee a cet endpoint et a /api/me).
- Garde restoreAbsentCollections() dans UserRbacProcessor qui respecte la
  semantique merge-patch+json : cle absente = preservee, cle = [] = videe,
  cle = [...] = remplacee. Restauration a partir du snapshot Doctrine des
  PersistentCollection pour roles / directPermissions / sites.
- Nouveaux criteres de validation + matrice de semantique.

Verification archi modular monolith : Commercial et Sites peuvent etre
desactives dans config/modules.php sans casser l'app (sidebar filtree,
switcher masque, endpoints admin rediriges via disabledRoutes).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/rbac/ticket-345-spec.md

@@ -572,3 +572,78 @@ Chaque etape doit etre revue (spec compliance + code quality) avant de passer a
 - Branche de travail : `feat/rbac-voter`, tiree de `feat/rbac-api`.
 - Pas de PR dediee : les commits #345 s'empilent sur la PR #3 existante ouverte vers `develop`.
 - Une fois la PR #3 mergee, la branche finale de l'epic RBAC (`feat/rbac-admin-ui` pour #346) partira de `develop`.
+
+## 18. Evolutions post-livraison — `UserRbacProcessor` defense in depth
+
+Voir aussi : `docs/sites/ticket-02-spec.md` § 10 pour la problematique cote
+Sites qui a motive cette evolution.
+
+### 18.1 — Semantique `merge-patch+json` respectee
+
+Le processor originel appliquait telles quelles les mutations produites par la
+denormalisation API Platform. Or API Platform reinstancie par defaut une
+`ArrayCollection` vide pour chaque propriete ManyToMany absente du payload,
+ce qui viole la semantique `application/merge-patch+json` : les cles absentes
+ne doivent PAS muter les proprietes correspondantes.
+
+Consequence concrete du bug : un PATCH minimal comme `{ "isAdmin": true }`
+detruisait silencieusement toutes les collections (`rbacRoles`,
+`directPermissions`, `sites`) du user cible.
+
+La garde `restoreAbsentCollections()` introduite dans `UserRbacProcessor`
+resout cela en :
+
+1. Injectant `RequestStack` pour lire le body JSON brut de la requete.
+2. Decodant les cles effectivement envoyees par le client.
+3. Pour chaque cle RBAC (`roles`, `directPermissions`, `sites`) absente du
+   payload : restaurant la collection a son etat d'origine a partir du
+   snapshot Doctrine (`PersistentCollection::getSnapshot()`), puis appelant
+   `takeSnapshot()` pour marquer la collection comme non-dirty (aucune query
+   `UPDATE` n'est emise sur les tables de jointure).
+4. No-op si la cle est presente (la denormalisation fait foi).
+
+Matrice finale :
+
+| Payload                         | Effet                               |
+|---------------------------------|-------------------------------------|
+| Cle absente                     | Propriete preservee (BDD inchangee) |
+| Cle presente = `[]`             | Collection videe (vidage explicite) |
+| Cle presente = `[...]`          | Collection remplacee                |
+
+### 18.2 — Nouvelle operation `GET /users/{id}/rbac`
+
+Le drawer d'edition (`UserRbacDrawer.vue`) ne peut plus dependre du payload
+de liste `/api/users` (groupe `user:list`) pour initialiser l'etat `sites`
+car ce groupe reste volontairement leger (cf. ticket Sites #02). Une
+operation `Get` dediee est ajoutee, symetrique au `Patch` existant :
+
+- URI : `/users/{id}/rbac`
+- Security : `is_granted('core.users.manage')` (plus strict que `.view`)
+- Groupe : `user:rbac:read` (contient `isAdmin`, `roles`, `directPermissions`,
+  `sites`).
+
+Le drawer charge desormais ce GET en parallele des referentiels au moment
+de l'ouverture, via un watch combine `[modelValue, user.id]` qui recharge
+correctement si le user change sans fermeture du drawer entre-temps.
+
+### 18.3 — Impact sur les tests
+
+`UserRbacProcessorTest` : le constructor gagne un argument `RequestStack`.
+Les tests existants injectent une `RequestStack` avec une `Request` vide
+(body `""`), ce qui rend la garde no-op — le comportement des assertions
+existantes est conserve. De nouveaux tests couvrent la garde :
+
+- PATCH sans cle `sites` ne mute pas la collection d'origine.
+- PATCH avec `sites: []` vide bien la collection (pas de regression du cas
+  "vidage explicite").
+- PATCH avec `sites: [...]` remplace comme avant.
+
+### 18.4 — Criteres de validation additionnels
+
+- [ ] `GET /users/{id}/rbac` retourne 200 avec `core.users.manage`, 403 sans.
+- [ ] Le payload contient `{ id, isAdmin, roles, directPermissions, sites }`.
+- [ ] `PATCH /users/{id}/rbac` avec cle absente preserve la collection BDD.
+- [ ] `PATCH /users/{id}/rbac` avec `[]` vide la collection et declenche
+      `ensureCurrentSiteConsistency` (cas sites).
+- [ ] Les 228 tests PHPUnit existants passent apres ajout du parametre
+      `RequestStack` au constructor.