fix(search-events): skip validation when the validate endpoint is unavailable

[EngRajabi]

Summary

Fixes #1497.

The search tools call the events validation endpoint (GET /api/0/organizations/{org}/events/validate/) before every search and treat any non-400 error as fatal. That endpoint was added to Sentry in mid-2026, so older deployments — including self-hosted instances — return 404, and the whole search fails with a misleading "Input Error" even though the underlying /events/ endpoint works fine.

This change treats a 404 from the validation endpoint as "validation is not supported on this deployment" rather than a bad request, and skips the validation gate so the search runs.

Changes

• SentryApiService.validateEvents now opts 404 into allowStatuses and returns null when the endpoint is unavailable (previously threw ApiNotFoundError). Return type is now EventsValidationResult | null.
• validateEventsSearch propagates the null result.
• Callers skip the gate on null:
  • runSearchEvents (packages/mcp-core/src/tools/support/search-events/search.ts) — runs the search instead of throwing.
  • assertEventsSearchIsValid — returns early.
  • The agent validateSearch tool (createValidateEventsSearchTool) — reports the candidate as valid with a note that validation was skipped.

Why this is safe on newer Sentry

On deployments that expose the endpoint, behavior is unchanged: 400 is still parsed as a validation result and 200 still validates normally. null is only produced for a 404, which on this endpoint means the route does not exist.

Tests

• New unit test in client.test.ts: validateEvents returns null on a 404.
• New tool-level test in search-events.test.ts: search_events still executes and returns data when the validate endpoint returns 404.
• pnpm --filter @sentry/mcp-core tsc ✅
• pnpm exec oxlint on changed source ✅
• Targeted suites (client.test.ts, search-events.test.ts, utils.test.ts) ✅ — 257 tests passing.

Verification against a real self-hosted instance

Reproduced against a self-hosted Sentry 25.8.0 (/events/validate/ → 404, /events/ → 200). With the published 0.42.0 the search tool failed with the 404; with this build the same call returns data:

search_errors(organizationSlug="sentry", fields=["count()"], sort="-count()", period="1h")
-> { "count()": 1520 }

Note: the search_events tool referenced in the issue was split into dataset-specific tools (search_errors, search_logs, search_traces, …) on main; all of them delegate to the shared runSearchEvents path fixed here.