Backport to 26.1: Fix covariance checks for SDL type extensions - #4444

Backport of #4420 to the 26.x maintenance branch.

Problem

GraphQL Java incorrectly rejected valid covariant field return types when the subtype relationship was introduced by an SDL extension rather than declared on the base type.

Object extension example

In this schema, Dog implements Pet through an extension. Returning Dog for a field declared as Pet is valid covariance:

type Query {
  base: Base
}

interface Pet {
  id: ID
}

type Dog {
  id: ID
}

extend type Dog implements Pet

type Base {
  foo: String
}

interface PetContainer {
  pet: Pet
}

extend type Base implements PetContainer {
  pet: Dog
}

The schema was incorrectly rejected because the covariance check only inspected the base definition of Dog and did not see extend type Dog implements Pet.

Interface extension example

The same problem affected interfaces inheriting from other interfaces through extensions:

type Query {
  base: Base
}

interface Pet {
  id: ID
}

interface WorkingPet {
  id: ID
}

extend interface WorkingPet implements Pet

interface PetContainer {
  pet: Pet
}

type Base implements PetContainer {
  pet: WorkingPet
}

WorkingPet is a valid covariant return type for Pet, but the extension-based relationship was previously ignored.

Union extension example

Union members introduced through extensions were also missed:

type Query {
  base: Base
}

type Cat {
  id: ID
}

type Dog {
  id: ID
}

union Pets = Cat

extend union Pets = Dog

interface PetContainer {
  pet: Pets
}

type Base implements PetContainer {
  pet: Dog
}

Dog is a valid subtype of Pets, but the previous check only inspected members declared on the base union.

Summary

TypeDefinitionRegistry stores base SDL definitions and extension definitions separately. This change makes the registry use the logical base-plus-extension relationships when:

• checking whether an object or interface is a possible type of an interface
• checking whether an object is a possible type of a union
• checking covariant field return types, including nested list and non-null wrappers
• finding object and interface implementations of an interface

This matches graphql-js behavior. graphql-js materializes extensions into its schema types before subtype checks; GraphQL Java retains separate AST definitions and now combines them when answering the equivalent registry queries.

Wrapped covariance

The same relationship is preserved while recursively checking list and non-null wrappers:

type Query {
  base: Base
}

interface Pet {
  id: ID
}

type Dog {
  id: ID
}

extend type Dog implements Pet

interface PetContainer {
  pets: [Pet]!
}

type Base implements PetContainer {
  pets: [Dog!]!
}

[Dog!]! remains a valid subtype of [Pet]!.

Unrelated types remain invalid

Extension relationships are matched by their declared interface and do not make unrelated types compatible:

type Query {
  base: Base
}

interface Pet {
  id: ID
}

interface Vehicle {
  id: ID
}

type Car {
  id: ID
}

extend type Car implements Vehicle

interface PetContainer {
  pet: Pet
}

type Base implements PetContainer {
  pet: Car
}

This schema is still rejected because Car implements Vehicle, not Pet.