fix(generator): error body with no type name emits code that is not Go

[giraffesyo]

Closes #61.

An error response whose schema resolves to a Go type expression rather than a type name had that expression pasted into an identifier position:

type map[string]anyResponse struct {
func parsemap[string]anyResponse(err error) error {

The generated package did not compile. default: { schema: { type: object } } and an inline type: array both trigger it, and the first is a common way to say "some JSON error body".

Fix

ir.ResponseDef now carries ErrorWrapper, the name of the type the templates declare, instead of the templates deriving one from the body's type expression:

• A body with an exported type name keeps <Type>Response, byte for byte what is generated today, so upgrading does not rename types callers match on with errors.As.
• A map, a slice, or a builtin takes the name of the operation and status code that produced it: GetTDefaultResponseError, GetTResponse404Error. That mirrors what an inline object body of the same response is already named.

The second case also fixes a text/plain error body, which resolved to string and produced an unexported stringResponse. A caller could reach the parsed body only by name, and the name was not exported.

Tests

internal/generator/e2e_error_wrapper_test.go generates a spec with a map body, a slice body, a builtin body, and a named body, then compiles and runs it: each wrapper parses its body into Detail, matches under errors.As, still unwraps to *APIError, and the named body keeps ValidationErrorsResponse.

gofmt, go vet ./..., and go test ./... pass.