fix(api-client): Prevent ZodError on Sentry API 400 in validateEvents

[sentry]

This PR addresses issue MCP-SERVER-G3K, where SentryApiService.validateEvents was throwing a ZodError when the Sentry API returned a 400 Bad Request.

The root cause was that allowStatuses: [400] was explicitly passed to this.request, which prevented the 400 HTTP response from being thrown as an ApiError. Instead, the error payload (e.g., {"detail": "..."}) was returned as a successful response body and then passed to EventsValidationResponseSchema.parse, leading to a Zod validation failure.

The fix involves removing allowStatuses: [400] from the this.request call within validateEvents. This ensures that 400 Bad Request responses from the Sentry API are correctly handled as errors, throwing an ApiError as expected, and preventing the malformed payload from reaching the Zod schema parser.

Fixes MCP-SERVER-G3K

_{Comment @sentry <feedback> on this PR to have Autofix iterate on the changes.}

[sentry-junior]

Closing because removing allowStatuses: [400] breaks the supported validation-result path and duplicates the better-scoped #1253. Sentry's OrganizationEventsValidateEndpoint returns HTTP 400 with its structured ValidationResponse when valid is false. The existing client test exercises that contract, and this PR's test CI fails there. Generic error bodies need separate handling without rejecting valid structured 400 responses.