feat(commercial) : messages de validation FR sur les contraintes back + garde-fou (ERP-107)

Audit et complete les messages des contraintes #[Assert\*] des entites metier
(pendant back du mapping d'erreur par champ front ERP-101) :

- Message FR explicite sur toutes les contraintes (Email, NotBlank, Length,
  Bic, Iban, PositiveOrZero, Count...) des entites Client, ClientContact,
  ClientAddress, ClientRib, Category, Role, User.
- Ajout des Assert\Length manquantes calees sur le length de la colonne ORM
  (telephones VARCHAR(20), siren, nTva, accountNumber, username...) : evite
  une erreur Postgres 500 non rattachee au champ au profit d'une 422 propre.
- Locale FR globale (symfony/translation + default_locale: fr) comme filet
  pour les messages natifs non surcharges.
- Garde-fou tests/Architecture/EntityConstraintsHaveFrenchMessageTest : echoue
  si une contrainte n'a pas de message FR explicite ou si Assert\Length.max
  diverge du length ORM (whitelist justifiee pour les formats Bic/Iban/Regex).
- Test fonctionnel du JSON 422 reel (message FR + propertyPath consommable
  par useFormErrors cote front).
- Convention documentee dans .claude/rules/backend.md.

Tests : 469 verts (1793 assertions).

.claude/rules/frontend.md

@@ -108,6 +108,18 @@ A NE PAS faire :
 - Seuls les deep links "de navigation metier" (ex: ouvrir un detail precis `/users/42`) sont dans l'URL
 - Exceptions autorisees **sur demande explicite** de l'utilisateur
 
+## Validation des formulaires (standard ERP-101)
+
+Regle transverse a TOUS les formulaires front (et a rappeler a l'ecriture de chaque ticket back/front portant un formulaire). Decidee en ERP-101 (declencheur : ecran « Ajouter un client » ERP-63).
+
+- **Champs obligatoires** : prop `required` du composant `Malio*` + etoile (asterisque) rouge dans le label. Ne JAMAIS griser le bouton « Valider » sans feedback : bouton toujours actif + erreurs affichees sous les champs.
+- **Couche de validation autoritaire = le back** : les RG sont re-validees serveur (mode strict). Au `422`, mapper `violations[].propertyPath` vers la prop `error` du champ via `extractApiViolations` (deja utilise par `useCategoryForm`). Zero duplication de RG, zero drift.
+- **Feedback instantane au blur** : uniquement requis / min / max / format (pas de re-implementation des RG metier cote front).
+- **Regles front-only** : celles sans equivalent back (ex. FK nullable cote back mais obligatoire selon un choix UI) sont validees et affichees cote front.
+- **Email — PAS de masque** : un email n'a pas de structure fixe. Normalisation via la prop `lowercase` de `MalioInputEmail` (trim + suppression des espaces + lowercase, coherent avec la normalisation serveur RG-1.21). Le format est valide par la prop `error` (violations serveur ou check au blur), jamais par un masque. Retirer tout shaping email ad hoc des ecrans.
+- **Contrat back attendu** : tout `422` issu d'un Processor/Validator doit porter `violations[].propertyPath` aligne sur les noms de champs du formulaire, pour etre consommable par `extractApiViolations`.
+- **Dependance** : le branchement des props `required` suppose `@malio/layer-ui` a jour (props `required` + etoile — MUI-41 / ERP-101).
+
 ## Interdits
 
 - `modules-loader.ts`, `.module.ts` — le scan des layers est automatique