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().

Do mô hình lập chỉ mục viết ra từ nội dung của issue.