fix: std error serializer should prefer err.name over error.constructor.name

[AlessioGr]

This change updates the default error serializer to use err.name (if present) instead of err.constructor.name when setting the type field.
This ensures human-readable error types even when class names are minified in production builds.

Problem

When using frameworks like Next.js (which use the SWC minifier), class names are renamed during build. This causes custom error types to appear as single-letter identifiers in logs.

Example:

[21:44:07] ERROR: Error running onInit function
    err: {
      "type": "h",  // <= wrong
      "message": "The following fields are invalid: ",
      "stack":
          h: The following fields are invalid:  // <= wrong
              /// ...
      "data": {
        "errors": []
      },
      "isOperational": true,
      "isPublic": false,
      "status": 400,
      "name": "h" // <= wrong
    }

Setting this.name = 'ValidationError' in the constructor partially fixes this, but err.type remains incorrect because Pino reads from err.constructor.name:

[21:44:07] ERROR: Error running onInit function
    err: {
      "type": "h",  // <= still wrong
      "message": "The following fields are invalid: ",
      "stack":
          ValidationError: The following fields are invalid:  // <= correct
              /// ...
      "data": {
        "errors": []
      },
      "isOperational": true,
      "isPublic": false,
      "status": 400,
      "name": "ValidationError" // <= correct
    }

The only other workaround is to forcibly override constructor.name, which is not safe since it’s a read-only property.

Solution

Prefer err.name (if defined) over err.constructor.name when setting type. I think this change should be made directly in the standard serializer rather than requiring users to provide their own error serializer, since the issue occurs in every Next.js production app that does not opt out of minification.

The same change needs to be made in pino-std-serializers, let me know what you think about this before I go ahead with that.

The drawback here is that "type" will simply be "Error" if the user forgets to override this.name. Feel free to close this PR if you think that is worse than the problem I described here.