feat(technique) : validations RG comptables server-side (RG-3.07 Virement/banque, RG-3.08 LCR/RIB) (ERP-136)

- Provider::validatePaymentTypeConsistency (Assert\Callback, miroir Supplier ERP-89) :
  RG-3.07 VIREMENT impose une banque (violation sur bank),
  RG-3.08 LCR impose au moins un RIB (violation sur paymentType).
- ProviderProcessor : docblock realigne (RG-3.07/3.08 portees par l'entite).
- AbstractProviderApiTestCase::bank() helper referentiel.
- ProviderAccountingValidationTest : 4 cas (negatif 422 / positif 200) par RG.

Les RG-3.03/3.05/3.09 (contraintes d'entite) et l'ecriture cloisonnee (gardes
processors, RG-3.17/2.13) etaient deja posees en ERP-133/134/135 et restent couvertes.

src/Module/Technique/Domain/Entity/Provider.php

@@ -140,6 +140,12 @@ class Provider implements TimestampableInterface, BlamableInterface
      */
     private const string REQUIRED_CATEGORY_TYPE_CODE = 'PRESTATAIRE';
 
+    /** Code pivot du type de reglement imposant une banque (RG-3.07). */
+    private const string PAYMENT_TYPE_VIREMENT = 'VIREMENT';
+
+    /** Code pivot du type de reglement imposant au moins un RIB (RG-3.08). */
+    private const string PAYMENT_TYPE_LCR = 'LCR';
+
     #[ORM\Id]
     #[ORM\GeneratedValue]
     #[ORM\Column]
@@ -291,6 +297,44 @@ class Provider implements TimestampableInterface, BlamableInterface
         }
     }
 
+    /**
+     * RG-3.07 / RG-3.08 : coherence du type de reglement comptable. Comme au M2
+     * (decision figee ERP-89, jumeau Supplier::validatePaymentTypeConsistency),
+     * ces RG inter-champs passent par une contrainte d'entite (Assert\Callback +
+     * ->atPath()) et NON par le ProviderProcessor, afin que chaque 422 porte un
+     * propertyPath exploitable par extractApiViolations (mapping inline sous le
+     * champ, pas un toast — convention ERP-101).
+     *  - RG-3.07 : paymentType = VIREMENT impose une banque -> violation sur `bank`.
+     *  - RG-3.08 : paymentType = LCR impose au moins un RIB -> violation sur
+     *    `paymentType` (les RIB n'ont pas de champ de formulaire ou s'ancrer quand
+     *    la liste est vide ; l'erreur s'affiche donc sous le select « Type de
+     *    règlement », binde cote front). Le 409 sur DELETE du dernier RIB en LCR est
+     *    porte par le ProviderRibProcessor (ERP-135).
+     *
+     * Ces champs vivant dans le groupe d'ecriture comptable (absent du POST, qui
+     * n'expose que provider:write:main), la contrainte ne mord en pratique que sur
+     * le PATCH de l'onglet Comptabilite.
+     */
+    #[Assert\Callback]
+    public function validatePaymentTypeConsistency(ExecutionContextInterface $context): void
+    {
+        $paymentCode = $this->paymentType?->getCode();
+
+        if (self::PAYMENT_TYPE_VIREMENT === $paymentCode && null === $this->bank) {
+            $context->buildViolation('La banque est obligatoire pour le type de règlement Virement.')
+                ->atPath('bank')
+                ->addViolation()
+            ;
+        }
+
+        if (self::PAYMENT_TYPE_LCR === $paymentCode && $this->ribs->isEmpty()) {
+            $context->buildViolation('Au moins un RIB est obligatoire pour le type de règlement LCR.')
+                ->atPath('paymentType')
+                ->addViolation()
+            ;
+        }
+    }
+
     public function getId(): ?int
     {
         return $this->id;