I was going to comment, but for readability this will be easier as an answer. I'm not sure this qualifies as an answer as I am not familiar with Gradle.

Regarding:

Are there tools, best practices ... that can help enforce strict module boundaries and encapsulation

...and keeping in mind:

I've structured each domain module into two sub-modules: api and impl.

This answer https://stackoverflow.com/a/62257045/39094 talks about access with regards to modules. On the basis of that I'd have thought you can have one module instead of two for a given domain, and just have it so only the API methods are set as public / accessible on the module. That way encapsulation can be enforced as you want it, and you have less modules and a simpler design.

Regarding Dependency Cycles. @SpaceTrucker makes an excellent point - just because calls go in both directions doesn't mean it's necessarily cyclical as in a death spiral, but it does indicate some potential coupling or at least that they work closely together to achieve something. Might be worth a design review, but doesn't mean you should panic right off the bat.

Some kind of static code review would probably be a good way to test for the presence of stuff like that, but I have not used static code analysis before so can't comment further. It looks like there's no shortage of tooling options for Java in that regard.

Internet search informs me that yes, you can use Gradle to control/initiate static code review - so yes it's possible, and based on my generic software engineering experience such an approach would not be an objectively bad idea.