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/sites/ticket-02-spec.md

@@ -590,3 +590,112 @@ Le ticket autorise un user sans sites (`sites: []`, `currentSite: null`). Mais a
 - [ ] `make test` passe toutes les suites (les 5 nouvelles + les existantes ajustees aux fixtures).
 - [ ] `make php-cs-fixer-allow-risky` propre sur les fichiers nouveaux et modifies.
 - [ ] Desactiver `SitesModule::class` dans `config/modules.php` ne casse pas les endpoints Core (la DB reste valide, les users conservent leurs sites meme si l'UI ne les expose plus).
+
+## 10. Evolutions post-livraison — drawer RBAC et defense in depth
+
+Apres la livraison initiale du ticket, un bug utilisateur a revele que le drawer
+`UserRbacDrawer.vue` demarrait toujours avec 0 site coche pour un user qui en
+avait en BDD, et que la sauvegarde ecrasait silencieusement les sites
+existants. Root cause : l'endpoint `GET /api/users` utilise le groupe `user:list`
+qui n'expose pas la collection `sites` (choix assume pour garder le payload
+leger et eviter toute fuite croisee site). Le drawer initialisait donc
+`selectedSiteIds` a partir d'un `user.sites` toujours `undefined`.
+
+Deux evolutions ont ete apportees pour corriger cela proprement sans elargir la
+surface de fuite de `/api/users` :
+
+### 10.1 — Nouvelle operation `GET /users/{id}/rbac`
+
+Une operation API Platform `Get` est ajoutee sur `User`, symetrique au `Patch`
+existant, sous la meme URI `/users/{id}/rbac` :
+
+```php
+new Get(
+    name: 'user_rbac_get',
+    uriTemplate: '/users/{id}/rbac',
+    security: "is_granted('core.users.manage')",
+    normalizationContext: ['groups' => ['user:rbac:read']],
+),
+```
+
+Raisons du design :
+- **Symetrie REST** : GET et PATCH partagent la meme URI et le meme groupe de
+  normalisation, documentation OpenAPI et appels clients lisibles.
+- **Separation list/detail** : `/api/users` (`user:list`) reste maigre — pas de
+  collection, pas de fuite. `/users/{id}/rbac` (`user:rbac:read`) porte le
+  detail riche requis par le drawer d'edition.
+- **Garde de permission plus stricte** : `core.users.manage` (et non `.view`)
+  — le detail RBAC est concu pour l'edition, pas la consultation.
+- **Isolation du couplage Sites** : la dependance au module Sites reste scopee
+  a cet endpoint et a `/api/me`. Elle n'est pas disseminee dans tous les
+  payloads de liste.
+
+Cote frontend (`UserRbacDrawer.vue`) :
+- `loadData(userId)` fetch desormais `/users/{id}/rbac` en parallele des
+  referentiels (roles, permissions, sites globaux).
+- Le watch combine `[modelValue, user.id]` recharge le detail a chaque
+  ouverture ou changement de user sans dependance fragile sur `props.user`.
+- Le type `UserListItem` perd `sites` (inutilise) ; un nouveau type
+  `UserRbacDetail` represente le payload du GET dedie.
+- La colonne "Sites" de `/admin/users` est retiree : l'info est consultee
+  dans le drawer. Cela supprime aussi le second fetch `/api/sites` sur la
+  page de liste.
+
+### 10.2 — Garde anti-ecrasement dans `UserRbacProcessor`
+
+API Platform denormalize les collections ManyToMany comme des `ArrayCollection`
+vides quand la cle JSON correspondante est absente du payload, violant la
+semantique `merge-patch+json` qui impose que les cles absentes ne mutent PAS
+les proprietes. Pour un PATCH qui ne veut toucher que `isAdmin`, cela
+detruirait tous les sites/roles/directPermissions du user.
+
+Le processor injecte desormais `RequestStack`, lit le body JSON brut au debut
+de `process()`, et pour chaque collection absente du payload restaure l'etat
+d'origine a partir du snapshot Doctrine :
+
+```php
+// Mapping cle JSON → accesseurs PHP (note : 'roles' → getRbacRoles)
+private const COLLECTION_MAP = [
+    'roles'             => ['getter' => 'getRbacRoles', ...],
+    'directPermissions' => ['getter' => 'getDirectPermissions', ...],
+    'sites'             => ['getter' => 'getSites', ...],
+];
+
+private function restoreAbsentCollections(User $user): void
+{
+    $payload = json_decode($this->requestStack->getCurrentRequest()?->getContent() ?? '', true);
+    foreach (self::COLLECTION_MAP as $jsonKey => $accessors) {
+        if (array_key_exists($jsonKey, $payload)) {
+            continue; // cle presente = la denormalisation fait foi
+        }
+        // cle absente = restaurer le snapshot PersistentCollection
+        // (voir implementation complete dans UserRbacProcessor.php)
+    }
+}
+```
+
+Semantique finale garantie :
+
+| Payload                         | Effet sur la collection            |
+|---------------------------------|------------------------------------|
+| Cle absente                     | Preservee (etat BDD inchange)      |
+| `"sites": []`                   | Collection videe explicitement     |
+| `"sites": ["/api/sites/1"]`     | Collection remplacee               |
+
+La garde `ensureCurrentSiteConsistency` continue de s'executer apres persist
+avec la meme logique : elle est triggered uniquement si la collection a
+effectivement mute (detection via `PersistentCollection::isDirty()` post-restore).
+
+### 10.3 — Criteres de validation additionnels
+
+- [ ] `GET /users/{id}/rbac` retourne 200 pour `core.users.manage`, 403 sinon.
+- [ ] Le payload contient `{ id, isAdmin, roles, directPermissions, sites }`.
+- [ ] `GET /api/users` ne contient plus `sites` (verification non-regression).
+- [ ] Ouvrir le drawer d'un user avec des sites en BDD affiche les cases
+      pre-cochees correspondantes.
+- [ ] `PATCH /users/{id}/rbac` avec `{ "isAdmin": true }` (sans autre cle) ne
+      modifie pas sites/roles/directPermissions.
+- [ ] `PATCH /users/{id}/rbac` avec `{ "sites": [] }` vide explicitement la
+      collection et bascule `currentSite` a `NULL` via la garde existante.
+- [ ] `PATCH /users/{id}/rbac` avec `{ "sites": [...] }` remplace la
+      collection comme auparavant.