feat(commercial) : amélioration et validation stricte des champs date (ERP-148)

- MalioDate v1.7.10 : exposition de l'état de validité et de la saisie brute
  invalide (@update:valid / @update:rawValue).
- Validation back-autoritaire du format : foundedAt n'accepte plus que l'ISO
  strict Y-m-d (Context DateTimeNormalizer) + collectDenormalizationErrors sur
  Client et Supplier -> toute saisie non-ISO renvoie un 422 porté sur le champ.
- Front : la saisie invalide est transmise au back, le message technique de
  type-error est surchargé par une clé i18n via le code de violation
  (resolveViolationMessage / VIOLATION_MESSAGE_I18N), affiché inline.
- Réorganisation des utils de formulaire sous utils/forms/.
- Tests back (cas piège 12/25/2026) + tests front (résolveur i18n).

.claude/rules/frontend.md

@@ -79,6 +79,7 @@ Regles :
 - **Toujours `{ toast: false }`** sur l'appel API qui veut un mapping inline (sinon le toast natif d'`useApi` masque le fin).
 - **Cas metier specifique** (ex: 409 doublon) : `setError('champ', message)` + toast explicite **avant** de deleguer le reste a `handleApiError`. Cf. `useCategoryForm` (doublon RG-1.07).
 - **Collections** (listes de sous-entites sauvees par un appel par ligne) : une erreur PAR LIGNE via un tableau `ref<Record<string, string>[]>` aligne sur l'index, peuple par `mapViolationsToRecord(error.response._data)` (util pur de `shared/utils/api.ts`). Le composant de ligne expose une prop `:errors` (`Record<string, string>`) bindee sur le `:error` de chaque champ. Cf. `ClientContactBlock` / `ClientAddressBlock` et les submits de `clients/new.vue` / `clients/[id]/edit.vue`.
+- **Message back technique → surcharge i18n par code** : la plupart des contraintes back portent un message FR explicite (affiche tel quel). Mais une 422 peut porter un message TECHNIQUE non montrable (ex. erreur de type API Platform sur une date non parsable : « Cette valeur doit être de type DateTimeImmutable|null. », voire en anglais selon la negociation). On le surcharge **cote front** via le `code` de violation (UUID Symfony fige, robuste — pas un match sur le texte) : table `VIOLATION_MESSAGE_I18N` + `resolveViolationMessage` dans `shared/utils/api.ts`, appliquee par `useFormErrors`. Ajouter un cas = une entree `code -> cle i18n`. Cas reference : date invalide (MalioDate forwarde la saisie brute via `@update:rawValue`, le back renvoie 422 sur `foundedAt` grace a `collectDenormalizationErrors`, le front affiche `errors.validation.invalidDate`).
 
 **Interdit** : se contenter d'un toast global sur une 422 quand le back identifie les champs fautifs (`propertyPath`). Reimplementer un mapping `if/else` par champ a la main au lieu d'`useFormErrors` / `mapViolationsToRecord`.