fix: batch resolver parent registration

[yiblet]

This schema:

type Query {
  organizations: [Organization!]!
}

type Organization {
  id: ID!
  users: [User!]! @goField(forceResolver: true, batch: true)
}

type User {
  id: ID!
}

The generated batch resolver receives all organizations at once:

Users(ctx context.Context, organizations []*Organization) ([][]User, error)

When omit_slice_element_pointers: true is set, organizations is generated as
[]Organization. The marshaller stored that value slice in the batch group, the
dispatcher asserted []*Organization, the assertion failed, and gqlgen fell back to one
call per organization. No error, correct data, N calls.

The marshaller now takes the address of each element before creating the group.

Other Registration Bugs Found Alongside It

• Nested lists. ast.Type.Name() follows through list wrappers, so [[Thing!]!]!
  reported Thing's kind and the outer list registered a [][]Thing under Thing. For
  an interface element it emitted a type switch on a slice, which does not compile.
  Only the innermost list registers now.
• Types that never read the group. The guard was schema-global: one batch resolver
  anywhere made every value-slice marshaller register parents, including introspection
  types, which cannot have batch resolvers at all. The federation fixtures drop from 28
  registrations to 2.
• Split schema files. Under follow-schema, each Data holds only its own file's
  objects, so an interface whose implementors live in different files registered only
  those sharing its file, a silent N+1 for the rest. addBuild now propagates the
  schema-wide set, as it already does for directives.

Also in This Branch

• resolveBatch_* no longer emits a four-deep nest per field; group lookup, parent type
  recovery, parent index and response key move behind graphql.BatchParentsFor and
  BatchParents.FieldResult. No existing runtime signature changes, so code generated by
  an older gqlgen still compiles.
• validate built its roots as import paths, whose ... wildcard skips testdata
  directories, so it matched no packages and compiled nothing. Every api/testdata
  fixture had gone unchecked since it landed. Roots now come from the output
  directory, and a fixture that deliberately fails to compile keeps it honest.
• Introspection traversal pre-sizes its slices and stops building throwaway maps to sort.
  A 2000-type schema goes from 8.7 ms and 15.8 MB to 5.3 ms and 7.7 MB, with byte
  identical output.
• Batch resolvers are documented for the first time, including the aliasing rule: for a
  []T field the parents point into the slice the marshaller is walking concurrently, so
  they must not be mutated or retained.
• The error for an unsupported type now says why, and prelude.resolvers.go, dead since
  __ types were excluded from batch resolvers, is deleted.

Tests

Each fix fails without it. Fixtures in api/testdata cover
omit_slice_element_pointers, nested lists, and split schema files, and count exact
occurrences because the nested-list bug registered a type twice rather than not at all.
The _examples/batchresolver test asserts results align with parents; reversing the
mapping in the resolver used to leave the package green.

go test ./... in both modules, go generate ./... a no-op, golangci-lint run ./...
clean.

I have:

• Added tests covering the bug / feature (see testing)
• Updated any relevant documentation (see docs)

[yiblet]

To show this working - I changed one of the models in the example to use a slice of values instead of slice of pointers. Previously this would mean we go back to running N individual queries. But with this change, a model with this structure would still batch correctly.

[yiblet]

For context, I use gqlgen with omit_slice_element_pointers and was experimenting with the new batch feature but realized it wouldn't work for me because of this issue. It seems like a quick fix, but this is my first time contributing to this codebase so I may be misunderstanding the right place to introduce this fix.

I'm happy to iterate on this based on feedback, let me know if there's something I should do differently to fix this bug.

[yiblet]

fixed the ci errors

[StevenACoffman]

@yiblet I just wanted to make a quick tweak to move some of your template logic into library helper code. I hope you don't mind, but I then noticed your tests were partly unfalsifiable (would always pass under some circumstances), and fixing those lead me to uncover a number of existing problems (not your fault). I got a little carried away, but this makes things a lot better.

[yiblet]

I don't mind at all! I deeply appreciate it. This issue was stopping me from being able to use the batch dataloader feature since I use value based slices instead of the pointer based ones.

I'm excited to try them out now. Thanks for the review & the merge.