GraphQL ignored-error-types should not rely only on ErrorClassification.toString()

### Problem Statement

I am using the GraphQL integration with:

- `io.sentry:sentry-spring-boot-4`
- `io.sentry:sentry-graphql-22`
- Sentry Java SDK `8.42.0`
- `com.graphql-java:graphql-java-extended-validation:24.0`

I want to ignore expected GraphQL validation errors produced by `graphql-java-extended-validation`.

The configuration looks like this:

```yaml
sentry.graphql.ignored-error-types:
- BAD_REQUEST
- UNAUTHORIZED
- FORBIDDEN
- NOT_FOUND
- ExtendedValidationError
```

This works well for enum-like ErrorClassification values, but it does not work reliably for errors from graphql-java-extended-validation.
From what I can see, SentryGraphqlInstrumentation currently resolves the error type with:

```java
error.getErrorType().toString()
```

and then compares that string with ignoredErrorTypes.
The problem is that graphql-java-extended-validation uses a private ResourceBundleMessageInterpolator.ValidationErrorType class. It does not expose a stable enum-like value via toString(). The semantic classification is exposed through ErrorClassification.toSpecification(...), which returns a map like:

```java
{
"type": "ExtendedValidationError",
"validatedPath": [...],
"constraint": "@..."
}
```

Because of this, I currently have to work around the issue by replacing the extended-validation MessageInterpolator and returning a custom ErrorClassification whose toString() returns ExtendedValidationError only when called from Sentry:

```java
override fun toString(): String {
if (stackWalker.callerClass == SentryGraphqlInstrumentation::class.java) {
return "ExtendedValidationError"
}

return super.toString()
}
```

That workaround is brittle and depends on Sentry internals.
This looks related to #2899, which added easier GraphQL error filtering. The current string-based filtering solves enum-like classifications, but it is hard to use with custom ErrorClassification implementations where toSpecification(...) carries the meaningful classification.

### Solution Brainstorm

Could Sentry support a more robust way to classify ignored GraphQL errors?

A few possible approaches:

1. When `error.getErrorType()` is present, call `errorType.toSpecification(error)` and, if it returns a map containing a `type` field, allow `ignored-error-types` to match that value.

2. Add a callback/predicate for GraphQL errors. This would allow applications to inspect GraphQLError, ErrorClassification, extensions, path, etc.
3. Pass the GraphQLError and/or ErrorClassification through the Sentry Hint, as mentioned in #2899, so users can filter these events in beforeSend without replacing the whole GraphQL instrumentation.

My preference would be option 1 for configuration compatibility, possibly combined with option 3 for advanced filtering.

This would also make the Sentry GraphQL integration work out of the box with `graphql-java-extended-validation`, which is an official companion library from the `graphql-java` project. Since Sentry Java already integrates with `graphql-java`, it would be helpful if expected validation errors from this commonly used library could be ignored without replacing the message interpolator or depending on `ErrorClassification.toString()`.

Start in SentryGraphqlInstrumentation and inspect how error.getErrorType().toString() is compared with ignored-error-types. Read graphql-java's ErrorClassification.toSpecification(...) behavior, then define the matching approach so ExtendedValidationError can be ignored without replacing the message interpolator or relying on toString().

Written by the indexing model from the issue text.