I'll give you several ideas to investigate. Hopefully one of them will lead you to the problem.

Are the three nodes really configured to use the same database?

Go to each different pod, get what configuration options each one is really using, and compare ALL the configuration files. Maybe they aren't really using the same database:

$ ejabberdctl dump_config /tmp/aaa.yml
$ cat /tmp/aaa.yml 

Is there any difference between the node that shows the rooms in get_user_rooms ?

Do the nodes correctly use the same database?

Register an account in the database, then check in the three nodes that they really get that account:

$ ejabberdctl registered_users localhost
admin

Maybe mod_muc and get_user_rooms doesn't behave as you expect

An account is registered in the cluster, and the user can login using those credentials in any node of the cluster. When the client logins to that account in a node, the session exists only in that node.

Similarly, the configuration of the rooms is stored in the cluster, and a room can be created in any node, and will be accessible transparently from all the other nodes.

The muc room in fact is alive in one specific node, and the other nodes will just point to that room in that node:

Rooms are distributed at creation time on all available MUC module instances. The multi-user chat module is clustered but the rooms themselves are not clustered nor fault-tolerant: if the node managing a set of rooms goes down, the rooms disappear and they will be recreated on an available node on first connection attempt.

So, maybe the ejabberd nodes connect correctly to the same database, but get_user_rooms doesn't show correct values, or the problem is only in the MUC service?