This seems more a deployment/infrastructure problem than a development problem to me.
I think disabling message listeners might not be such a great idea from design point of view. You certainly will run upon a moment in time in which you forget to enable/disable certain listeners/handlers (especially dangerous for event listeners) with all undesired and strange behaviour as a result.
It think it is a safer and more reliable approach to deploy service B and take service A offline. If you discover a bug on service B, you can relatively fast redeploy service A rolling-back to the previous logic. Since you mention it is a query service, I guess no much harm can be done. I assume your services are running as Docker containers making the downtime short when re-activating an older container to replace the new one.
If you really need no downtime at all. A suggestion worth evaluating could be to spin up service B and use an API gateway to route all traffic to service B before you take service A offline. If you discover a bug on service B, redeploy service A again and reroute all traffic to service A again at the API gateway and take the buggy service offline again. It involves a certain risk though… Keep in mind e.g. for query handlers (from the docs):
In case multiple handlers are registered, it is up to the implementation of the Query Bus to decide which handler is actually invoked
Multiple query handlers for the same point-to-point query will very likely result in unpredictable behaviour.