Having to wait for the server for the set of legal moves feels like a hack. It's way simpler to have the client have its own copy of the game state, and allow "query" methods (methods that fetches data about the game state but don't modify it). This allows you to make _powerful_ UI, which can show any kind of information the user needs about the game like predictions about what would happen if a move is done, computing things so the user doesn't need to.
If I had to redo it, I would use a paradigm similar to how boardgame.io[2] works, which is similar to how fixed lockstep works. The server and the clients all keep a full state of the game and when a player makes an action, it is transmitted to all the actors, who apply this action to their own state of the game. Since the game rules are deterministic, the final state of the game will be the same for each actor. The only 2 complex to handle are randomness and secrets (the former can actually be solved by the later), but overally, the complexity is managed elegantly and you can separate networking code from gameplay code easily.
Actually, one of my future possible project would be to make a library similar to boardgame.io, but less opiniated, and in the future, offer a platform to easily host and launch a game coded with it.