fix(graphql): support specification error types

[IamPritamAcharya]

📜 Description

Allow GraphQL ignored-error-types to match semantic error classifications exposed through ErrorClassification.toSpecification(error).

The integration now checks:

• the existing ErrorClassification.toString() value;
• a string returned directly by toSpecification(error);
• the "type" value from a specification map;
• the existing extensions-based fallback when no classification is available.

Malformed or unusable specifications fall back to capturing the error. Non-fatal failures from third-party classification implementations are handled safely, while fatal failures are rethrown through ExceptionUtils.rethrowIfFatal.

💡 Motivation and Context

Custom classifications such as those used by graphql-java-extended-validation expose their semantic type through a specification map:

{
  "type": "ExtendedValidationError"
}

Previously, filtering relied on ErrorClassification.toString(), which can return an unstable object identity string. This prevented ExtendedValidationError from being configured through ignored-error-types.

resolves: #6020
resolves: JAVA-713

💚 How did you test it?

• Added regression tests covering:
  • legacy toString() matching;
  • direct string specifications;
  • map-based "type" specifications;
  • ExtendedValidationError;
  • null, missing, unexpected, and throwing specifications;
  • extensions fallback;
  • non-ignored error capture.
• Ran all tests for sentry-graphql-core, sentry-graphql, and sentry-graphql-22.
• Ran module-level formatting, API compatibility, Animal Sniffer, and check tasks.
• Confirmed no public API dump changes.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

None.