[ERP-53] Migrer les tables Client + sous-collections + référentiels comptables (#27)

## Contexte
Ticket Lesstime : **#53** (ERP-53) — premier ticket back du M1 (Répertoire clients).
Spec back : `docs/specs/M1-clients/spec-back.md` § 3.2 + § 3.3.

## Implémentation
- Migration Doctrine `migrations/Version20260601000000.php` (12 tables) + fixture `CategoryTypeFixtures`.
- **4 référentiels comptables** seedés : `tva_mode` (3), `payment_delay` (3), `payment_type` (4), `bank` (3).
- **Table `client`** : 31 colonnes (formulaire + Information + Comptabilité + archive + soft-delete + Timestampable/Blamable).
- **4 sous-collections** : `client_category` (M2M), `client_contact`, `client_address`, `client_rib` + **3 jointures** d'adresse (`client_address_site`, `client_address_contact`, `client_address_category`).
- **4 CHECK** : mutex distributor/broker, contact name, address prospect exclusif, billing email conditionnel.
- **1 index partiel unique** : `uq_client_company_name_active` sur `LOWER(company_name) WHERE is_archived=false AND deleted_at IS NULL` (décision Q4 — **pas** d'unicité siren/email).
- **Seed `category_type`** : DISTRIBUTEUR / COURTIER / SECTEUR / AUTRE (`ON CONFLICT (code) DO NOTHING` en migration pour la prod, + fixture idempotente pour dev/test purgés).
- `COMMENT ON COLUMN` sur **chaque** colonne (convention ERP-67, garde-fou vert).

## RG couvertes (niveau BDD)
RG-1.03 (mutex distrib/broker), RG-1.05 (contact name), RG-1.06/07/08 (adresse prospect exclusif), RG-1.11 (billing email), RG-1.16 (unicité company_name — RG-1.15/1.17 supprimées par Q4), RG-1.22 (is_archived + archived_at).

## Écarts assumés vs spec (cf. docblock migration + cahier de test du ticket)
1. **Namespace `migrations/` racine** au lieu de `App\Module\Commercial\…` : vérifié empiriquement que Doctrine 3.9.6 (AlphabeticalComparator → strcmp FQCN) trierait le namespace Commercial **avant** `DoctrineMigrations` → migration client exécutée avant user/category/site → échec FK sur base vide. Le namespace racine garantit l'ordre par timestamp.
2. **DDL aligné Doctrine** : `INT GENERATED BY DEFAULT AS IDENTITY` + `TIMESTAMP(0) WITHOUT TIME ZONE` (et non SERIAL/TIMESTAMPTZ) → forward-compatible avec les entités du ticket 1.1 (schema:update no-op).
3. **Seed `category_type (code, label)` sans `position`** : la table M0 n'a pas de colonne `position` (coquille du pseudo-SQL § 3.3).

> **Note ERP-54** : à l'arrivée des entités Client*, `schema:update` droppera leurs COMMENT + l'index partiel. Prévoir l'ajout au `ColumnCommentsCatalog` + recréation de l'index dans `test-db-setup` (pattern `uq_category_name_type_active`).

## Tests
- `make php-cs-fixer-allow-risky` ✓
- `make db-reset` ✓ + vérifications psql manuelles (8 cas : CHECK, unicité partielle, archivage, siren/email dupliqués, seeds)
- `make test` ✓ — **312 tests OK, 0 régression**

---------

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

docs/specs/M1-clients/spec-back.md

@@ -235,7 +235,9 @@ Le **formatage `XX XX XX XX XX`** est fait à l'affichage côté front (filter V
 
 ### 3.2 Migration Doctrine — SQL Postgres
 
-Namespace : `App\Module\Commercial\Infrastructure\Doctrine\Migrations` (modulaire, post-init). Fichier : `Version20260601000000.php` (à dater par le dev).
+Namespace : **`DoctrineMigrations` (racine `migrations/`)** — fichier `migrations/Version20260601000000.php` (à dater par le dev).
+
+> **Décision 29/05/2026 (vérifiée empiriquement en dev)** : cette migration crée un **schéma avec FK cross-module** (`user`, `category`, `site`) → elle a la même dépendance d'ordre que les migrations d'init. Le namespace modulaire `App\Module\Commercial\…` casse `make db-reset` : Doctrine Migrations 3.x trie par **FQCN alphabétique** (`App\…` < `DoctrineMigrations\…`), donc la migration client tournerait AVANT `user`/`category`/`site` et ses FK échoueraient. Elle relève donc de l'**exception racine** de la règle ABSOLUE n°11 (même choix que la migration cross-module ERP-67). Le namespace modulaire reste réservé aux évolutions post-schéma (ajout de colonnes/index). La correction long-terme (MigrationsComparator custom, tri par timestamp) est un ticket archi dédié, hors scope M1.
 
 ```sql
 -- =====================================================================
@@ -475,7 +477,14 @@ INSERT INTO category_type (code, label, position) VALUES
     ('AUTRE',        'Autre',        99);
 ```
 
-> **Note** : le CRUD admin de `CategoryType` reste HP (cf. M0). Le seed est fait via migration ou fixture déclenchée à chaque `make db-reset`.
+> **Note** : le CRUD admin de `CategoryType` reste HP (cf. M0).
+>
+> **Seed en DEUX endroits (décision 29/05, vérifiée empiriquement)** : le `make db-reset` lance les fixtures, dont le purger Doctrine **vide `category_type`** (entité M0 mappée) avant `load()` → un seed posé uniquement en migration disparaît en dev/test. Donc :
+> 1. **Migration** (`ON CONFLICT (code) DO NOTHING`) → sert en **prod** (pas de fixtures).
+> 2. **Fixture Commercial idempotente** (ex. `CommercialReferentialFixtures`) re-seedant les 4 types → survit au `db-reset`, satisfait le critère « 4 types présents après db-reset ».
+>
+> ⚠ **À venir en ERP-54** : `tva_mode` / `payment_delay` / `payment_type` / `bank` ne sont pas encore des entités mappées au M1.0 → le purger ne les touche pas, leur seed migration survit. **Dès qu'ERP-54 crée leurs entités, ils seront purgés au db-reset** → il faudra les ajouter à la même fixture référentielle.
+> 🔗 **Coordination ERP-68** : ERP-53 pose la fixture référentielle minimale (4 category_types). ERP-68 l'**étend** (clients de démo, ~12-15) sans la dupliquer.
 
 ### 3.4 Entité `Client` — squelette
 
@@ -971,7 +980,7 @@ Cf. § 2.6. Pattern Shared standard.
 - [ ] **Compta POST création** : Compta → 403 (pas de `manage` global)
 - [ ] **PATCH mix groupes** : Bureau envoie payload avec `companyName` (write:main) + `siren` (write:accounting) → **403 sur tout le payload** (strict, RG-1.28)
 - [ ] **Audit** : POST + PATCH + archive → audit_log avec entity_type='Client', `changes` correct ; **iban/bic présents dans le diff** (pas d'AuditIgnore, cf. § 6.1)
-- [ ] **Migration** : `make db-reset` → schéma OK, seed des 4 référentiels + CategoryType (DISTRIBUTEUR/COURTIER/SECTEUR/AUTRE) présent ; index partiel unique `uq_client_company_name_active` présent (un seul — cf. Q4)
+- [ ] **Migration** : `make db-reset` → schéma OK ; migration en racine `migrations/` (namespace `DoctrineMigrations`, ordre garanti) ; 4 référentiels comptables seedés ; **4 CategoryType présents APRÈS db-reset** (via fixture idempotente, car le purger vide category_type) ; index partiel unique `uq_client_company_name_active` présent (un seul — cf. Q4)
 
 ### 8.2 Cas à couvrir (front — Vitest)