fix(commercial) : validation onglet compta LCR + controle croise BIC/IBAN (ERP-118) (#78)

## ERP-118 — Validation onglet Comptabilité (LCR / RIB)

### 1. Fix — 422 « Au moins un RIB est obligatoire pour le type de règlement LCR »

L'onglet Comptabilité envoyait le `PATCH /clients/{id}` des scalaires (`paymentType=LCR`) **avant** le `POST /clients/{id}/ribs`. Or le back valide RG-1.13 (LCR ⟹ ≥1 RIB persisté) sur ce PATCH, en lisant les RIB en base — vides à ce stade. Résultat : 422, et le `return` empêchait la création des RIB. Premier passage en LCR impossible (deadlock).

**Correctif :** inverser l'ordre — RIB d'abord, puis PATCH des scalaires.
- `new.vue` : `POST/PATCH RIB` → `PATCH scalaires`.
- `[id]/edit.vue` : ordre universel `CREATE/UPDATE RIB` → `PATCH scalaires` → `DELETE RIB retirés` (suppressions après le PATCH : le guard back n'autorise la suppression du dernier RIB qu'une fois quitté LCR). Corrige au passage un 409 latent sur le swap du dernier RIB en LCR.

### 2. Feat — contrôle croisé pays BIC/IBAN

`Assert\Bic(ibanPropertyPath: 'iban')` sur `ClientRib` et `SupplierRib` : le pays du BIC (positions 5-6) doit correspondre au pays de l'IBAN (positions 1-2). Un BIC et un IBAN valides isolément mais de pays différents → 422, violation portée par le champ `bic` avec message FR (`ibanMessage`), mappée inline côté front. Aucune modif front nécessaire.

### Tests

- Tests fonctionnels du mismatch (BIC DE + IBAN FR → 422 sur `propertyPath=bic`, message FR) côté client et fournisseur.
- Suite back complète au vert (garde-fou `EntityConstraintsHaveFrenchMessageTest` inclus), suite front Vitest au vert.

### Points d'attention

- **Durcissement de RG** (cross-check BIC/IBAN) hors spec initiale : des RIB existants avec BIC/IBAN de pays différents deviendraient non modifiables sans correction.
- L'orchestration de submit n'est pas couverte par un test unitaire (pas d'infra de test composant sur ces écrans) — vérification golden path recommandée.

Reviewed-on: #78
Co-authored-by: tristan <tristan@yuno.malio.fr>
Co-committed-by: tristan <tristan@yuno.malio.fr>

src/Module/Commercial/Domain/Entity/SupplierRib.php

@@ -44,7 +44,8 @@ use Symfony\Component\Validator\Constraints as Assert;
  * Tout passe par le SupplierRibProcessor (RG-2.08 sur DELETE).
  *
  * Validation IBAN/BIC : Assert\Iban + Assert\Bic standard Symfony (pas de controle
- * banque reelle). Audite (#[Auditable]) + Timestampable / Blamable.
+ * banque reelle), avec controle croise pays BIC/IBAN (ibanPropertyPath). Audite
+ * (#[Auditable]) + Timestampable / Blamable.
  */
 #[ApiResource(
     operations: [
@@ -105,9 +106,15 @@ class SupplierRib implements TimestampableInterface, BlamableInterface
 
     // Bic/Iban bornent deja le format (et donc la longueur) : pas de Length
     // redondant calee sur la colonne (auto-exempte du miroir ERP-107).
+    // ibanPropertyPath : controle croise — le pays du BIC (positions 5-6) doit
+    // correspondre au pays de l'IBAN (positions 1-2). Violation portee sur `bic`.
     #[ORM\Column(length: 20)]
     #[Assert\NotBlank(message: 'Le BIC est obligatoire.', normalizer: 'trim')]
-    #[Assert\Bic(message: 'Le BIC n\'est pas valide.')]
+    #[Assert\Bic(
+        message: 'Le BIC n\'est pas valide.',
+        ibanPropertyPath: 'iban',
+        ibanMessage: 'Le BIC ne correspond pas au pays de l\'IBAN.',
+    )]
     #[Groups(['supplier:read:accounting', 'supplier:write:accounting'])]
     private ?string $bic = null;