Translate form validation errors

Split out of the API error rework (see "API error codes: envelope, status fallback and guardrails").

Why this is its own ticket

The ugliest errors users actually see don't come from a throw in a service — they come from the global ValidationPipe (main.ts), which emits class-validator's raw English strings ("email must be an email"), joined with ", " by the web client.

No business error code will ever cover those. It's a distinct mechanism, and it's the one with the highest perceived UX impact. It's also independent from the code registry — it can ship before or after it.

Scope

• exceptionFactory on the ValidationPipe → code: "validation.failed" plus a structured details array of { field, constraint } instead of a flat string array.
• Web side: a generic global message ("Le formulaire contient des erreurs") and per-field errors rendered under each input.
• Field errors are translated by constraint name (isEmail, minLength, isNotEmpty, isInt, max…) with the constraint's arguments as interpolation params — roughly 15 constraints cover the whole app, so it's a bounded table, not a per-field message catalogue.
• Forms that already do their own client-side validation should reuse the same translation table so the wording matches whether the check fired locally or server-side.

Note

The API keeps emitting field names and constraint names, never prose. Locale-agnostic, same rule as the rest of the rework.

~1 day.