Possible memory leak using experimental feature Execution Cancellation

### Issue workflow progress

_Progress of the issue based on the
[Contributor Workflow](https://github.com/the-guild-org/Stack/blob/master/CONTRIBUTING.md#a-typical-contributor-workflow)_

- [ ] 1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox
> Make sure to fork this template and run `npm run generate` in the terminal.
>
> Please make sure the GraphQL Tools package versions under `package.json` matches yours.
- [ ] 2. A failing test has been provided
- [ ] 3. A local solution has been provided
- [ ] 4. A pull request is pending review

---

**Describe the bug**

While analyzing a possible memory leak in a graphql-yoga server with Node.js heap profiling and Chrome dev-tools I saw some suspicious results which could indicate a memory leak in @graphql-tools/executor.

The first screen shot shows the comparison of two heap snapshots of the service, the latter one (Snapshot 4) received about 10000 mutation requests more than Snapshot 3. Memory is very stable except some new allocations, see the red frame. The number of new allocations is a multiple (x2, x4 or x6) of the received requests.

If I drill down the source of the allocations, it points to this place (@graphql-tools/executor/cjs/execution/execute.js):

**To Reproduce** Steps to reproduce the behavior:

If these are really some leaking event listeners every graphql-yoga server using @graphql-tools/executor should leak a little memory over time.

**Expected behavior**

No leaking listeners

**Environment:**

- OS: Arch Linux, Kernel 6.17
- `@graphql-tools/...`:
- "@graphql-tools/executor-http": "3.0.4",
- "@graphql-tools/merge": "9.1.1",
- "@graphql-tools/schema": "10.0.25",
- "@graphql-tools/stitch": "10.0.2",
- "@graphql-tools/utils": "10.9.1",
- "@graphql-tools/wrap": "11.0.1",
- "graphql": "16.11.0",
- "graphql-fields": "2.0.3",
- "graphql-scalars": "1.24.2",
- "graphql-tag": "2.12.6",
- "graphql-yoga": "5.16.0",
- NodeJS: 24.9.0

**Additional context**

Sorry that I didn´t provide tests or a reproduction repo (yet). Tests may be very difficult to write and if there is really a leaking listener problem one should be able to reproduce the issue (with Node.Js heap profiler and Chrome dev tools heap snapshot comparison) with every program using @graphql-tools/executor.

Maybe I am totally wrong here and the behavior I see in the snapshot comparison is normal.