Preserve Structured Validation Error Context in validateAndTransformBody / validateAndTransformQuery

[Fitch24]

Description

Currently, when the core zodValidator executes inside validation middlewares like validateAndTransformBody or validateAndTransformQuery, the original ZodError structure is caught, stringified via formatError(), and discarded. It is replaced with a standard MedusaError(MedusaError.Types.INVALID_DATA, ...) string message.
While this works well for generic text logging, it destroys the underlying array of validation issues (paths, codes, and specific field errors). This makes it incredibly difficult for headless storefront integrations to display context-aware, field-by-field validation errors to consumers without resorting to brittle error string parsing.

Current validation error response:

{
  "type": "invalid_data",
  "message": "Invalid request: email is invalid, password must be longer than 8 characters"
}

Suggested validation error response:

{
  "type": "invalid_data",
  "message": "Invalid request: email is invalid, password must be longer than 8 characters",
  "errors": [
    {
      "field": "email",
      "message": "Invalid email"
    },
    {
      "field": "password",
      "message": "String must contain at least 8 character(s)"
    }
  ]
}

Suggested Solution

We should allow validation errors to carry an optional context or details property on the MedusaError class, or natively forward the underlying structural arrays when formatting errors.
Ideally, a backward-compatible solution would expand MedusaError to house metadata payload fields, which the default API errorHandler can conditionally serialize into the JSON response envelope.