Transforms break nested stitched schemas

**Describe the bug**

Using transforms with stitched schemas seems to skip adding the `selectionSet` after the first nesting, e.g. using terminology from the documentation examples `user => posts` works but `user => posts => user` (contrived I know) skips adding the `selectionSet` which results in an error. There's a few issues from v5 and v7 that seem similar to this, but they don't seem transforms-related.

**To Reproduce**

Repro repo here: https://github.com/CygnusRoboticus/double-stitch-repro. I started building something resembling my use-case with multiple backing transformed GQL services, but found that the example from the docs [here](https://www.graphql-tools.com/docs/schema-stitching/stitch-schema-extensions#extending-transformed-schemas) exhibits the same problem and went with that instead. Removing the transforms corrects this issue and allows the stitched schemas to select the nested resolvers indefinitely.

EDIT: To clarify and help make this a little more searchable
```
# with transforms
query {
userById(id: 1) {
posts {
# manually selecting this avoids the error
# userId
user {
id
}
}
}
}
```
yields
```
{
"errors": [
{
"message": "Cannot return null for non-nullable field User.posts.",
"path": [
"userById",
"posts"
]
// additional properties omitted for brevity
}
],
"data": {
"userById": null
}
}
```

**Expected behavior**

I expect to be able to execute stitched resolvers from transformed schemas without having to manually select the values indicated in their `selectionSet` configuration.

**Environment:**

- OS: Linux
- NodeJS: 14.18.0
- `@graphql-tools/delegate`: 8.4.3
- `@graphql-tools/mock`: 8.5.1
- `@graphql-tools/stitch`: 8.4.3
- `@graphql-tools/utils`: 8.6.1
- `@graphql-tools/wrap`: 8.3.3

**Additional context**

The failure above is present in the docs, but my actual use-case is fairly convoluted. I'm actually seeing this issue with one transformed schema being stitched into another transformed schema. I also recently did an upgrade from v6, but again the failure mode above is from the docs so I am unsure if that is related.

Start by running the linked double-stitch-repro and reproducing the nested user → posts → user query, then compare it with the schema-stitching documentation example for extending transformed schemas. Trace the stitched resolver and selectionSet behavior across the transformed schemas. Done means nested transformed stitched resolvers execute without requiring manual selection of the configured fields, with regression coverage for the reported query.

Written by the indexing model from the issue text.