[ERP-76 + ERP-68] Validations d'adresse client (RG → 422) + fixtures démo Catalog/Commercial (#41)

Stack de 2 tickets sur une branche (squash sur `develop`).

## ERP-76 (#500) — Validations d'adresse Client → 422

Les règles d'intégrité de l'onglet Adresse étaient soit non implémentées (RG-1.29), soit rejetées en 500 par les CHECK Postgres (RG-1.06/07/08/11). Elles sont désormais portées par des `Assert\Callback` applicatifs sur `ClientAddress`, qui remontent une **422 Hydra avant la base** ; les CHECK BDD restent en filet de sécurité.

- `validateProspectExclusivity` — `isProspect` exclusif de `isDelivery`/`isBilling` (RG-1.06/07/08).
- `validateBillingEmailPresence` — `billingEmail` obligatoire ssi `isBilling` (RG-1.11).
- `validateCategoryTypes` — refuse une catégorie de type DISTRIBUTEUR/COURTIER sur une adresse (RG-1.29, violation `categories`), via `CategoryInterface` (règle n°1 respectée).

Tests `ClientAddressTest` durcis (≥400 → **422 explicite**) + 4 cas RG-1.29. Cahier de test M1 mis à jour.

## ERP-68 (#486) — Fixtures démo Catalog + Commercial (dev only)

- `CategoryFixtures` (Catalog) : 12 catégories sur les 4 types.
- `ClientFixtures` (Commercial) : 14 clients couvrant les cas RG (dépendant distributeur/courtier RG-1.03, LCR + 2 RIB RG-1.13, Chèque sans RIB, multi-adresses Prospect/Livraison/Facturation RG-1.06/07/08/11, prospect seul, 3 contacts + tél. secondaire RG-1.05/1.02, archivé RG-1.22, onglet Information complet, multi-catégories M2M).

Résolution inter-modules via les seuls contrats Shared (`CategoryInterface`, `SiteProviderInterface`). Valeurs brutes normalisées par `ClientFieldNormalizer`. Données conformes aux CHECK BDD **et** aux validators ERP-76. Idempotentes (lookup `companyName`/`name`). **Garde-fou** : les deux fixtures sont no-op en environnement `test` (la base de test reste un socle minimal ; pas de pollution des comptages ni des cleanups FK).

## Bonus — idempotence fixtures

`AppFixtures` (admin/alice/bob) rendu idempotent via lookup par username : `doctrine:fixtures:load --append` est désormais rejouable sans erreur sur tout le jeu de fixtures.

## Vérifications

- `make test` : **436/436 vert** (0 échec/erreur).
- `make php-cs-fixer-allow-risky` OK.
- `make db-reset` charge sans erreur ; 2 runs `--append` consécutifs = idempotent (0 doublon ; 7 users / 14 clients / 12 catégories stables).
- `admin/admin` intact.

---------

Co-authored-by: Matthieu <contact@malio.fr>
Reviewed-on: #41
Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>

src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php

@@ -28,6 +28,11 @@ use Symfony\Component\PasswordHasher\Hasher\UserPasswordHasherInterface;
  * systeme de maniere idempotente avant de rattacher les utilisateurs, afin
  * que le workflow "make db-reset && make fixtures" reste one-shot.
  *
+ * Idempotence complete (y compris `doctrine:fixtures:load --append`, sans
+ * purge) : roles via ensureSystemRole, utilisateurs via ensureUser (lookup par
+ * username). Rejouer la fixture ne cree donc aucun doublon ni violation
+ * d'unicite de username.
+ *
  * Dependance explicite a SitesFixtures (ticket 2) : les 3 sites Chatellerault,
  * Saint-Jean et Pommevic doivent etre presents en base avant d'etre rattaches
  * aux users. L'inversion volontaire de l'ordre (AppFixtures ← SitesFixtures)
@@ -75,8 +80,7 @@ class AppFixtures extends Fixture implements DependentFixtureInterface
         $saintJean     = $this->requireSite('Saint-Jean');
         $pommevic      = $this->requireSite('Pommevic');
 
-        $admin = new User();
-        $admin->setUsername('admin');
+        $admin = $this->ensureUser($manager, 'admin');
         $admin->setIsAdmin(true);
         $admin->setPassword($this->passwordHasher->hashPassword($admin, 'admin'));
         $admin->addRbacRole($adminRole);
@@ -87,8 +91,7 @@ class AppFixtures extends Fixture implements DependentFixtureInterface
         $admin->setCurrentSite($chatellerault);
         $manager->persist($admin);
 
-        $alice = new User();
-        $alice->setUsername('alice');
+        $alice = $this->ensureUser($manager, 'alice');
         $alice->setPassword($this->passwordHasher->hashPassword($alice, 'alice'));
         $alice->addRbacRole($userRole);
         // Alice : un seul site, site courant = ce site.
@@ -96,8 +99,7 @@ class AppFixtures extends Fixture implements DependentFixtureInterface
         $alice->setCurrentSite($chatellerault);
         $manager->persist($alice);
 
-        $bob = new User();
-        $bob->setUsername('bob');
+        $bob = $this->ensureUser($manager, 'bob');
         $bob->setPassword($this->passwordHasher->hashPassword($bob, 'bob'));
         $bob->addRbacRole($userRole);
         // Bob : site different de Alice, pour prouver le filtrage par site
@@ -135,6 +137,27 @@ class AppFixtures extends Fixture implements DependentFixtureInterface
         return $role;
     }
 
+    /**
+     * Retourne l'utilisateur correspondant au username, en le creant s'il
+     * n'existe pas encore. Rend la fixture idempotente y compris en
+     * `doctrine:fixtures:load --append` (sans purge) : sans ce lookup, recreer
+     * « admin » / « alice » / « bob » violerait l'unicite de username. Meme
+     * esprit que ensureSystemRole ci-dessus et RbacDemoFixtures::ensureDemoUsers.
+     */
+    private function ensureUser(ObjectManager $manager, string $username): User
+    {
+        $user = $manager->getRepository(User::class)->findOneBy(['username' => $username]);
+
+        if (null !== $user) {
+            return $user;
+        }
+
+        $user = new User();
+        $user->setUsername($username);
+
+        return $user;
+    }
+
     private function requireSite(string $name): SiteInterface
     {
         $site = $this->siteProvider->findByName($name);