Mutations can be asynchronous
Mutations are generally not synchronous in Apollo Client. The client can wait for a mutation result as long as it needs to. You might not want your GraphQL service to keep the HTTP connection open for that duration and this seems to be the problem you are dealing with here. Your approach responding to mutations goes against how GraphQL is designed to work and that starts to create complexity that - in my opinion - you don't want to have.
Solve the problem on the implementation level - not API level
My idea to make this work better is the following: Follow the GraphQL spec and dogmatic approach. Let mutations return mutation results. This will create an API that any developer is familiar working with. Instead treat the delivery of these results as the actual problem you want to solve. GraphQL does not specify the transport protocol of the client server communication. If you have websockets running between server and client already throw away HTTP and completely operate on the socket level.
Leverage Apollo Client's flexible link system
This is where Apollo Client 2 comes in. Apollo Client 2 lets you write your own network links that handle client server communication. If you solve the communication on the link level, developers can use the client as they are used to without any knowledge of the network communication details.
I hope this helps and you still have the chance to go in this direction. I know that this might require changes on the server side but could be totally worth it when your application is frontend heavy (as most applications are these days)