Architectural patterns are not meant to be followed religiously. Like any other pattern in software, they are well tested and defined solutions for specific problems, but flexible enough to be adapted. Answering your questions:
So, should Entities:
It depends on your domain. Sometimes, you need Entities that are capable of transforming or updating their state. On the other hand, you might only need a data representation of a given concept, with no state at all (e.x.: data classes in Kotlin). On Android, for instance, it is pretty common to have an anemic model, and that is OK because it fits the domain most of the times.
Again, depends on your domain. Interactors already serve as a boundary between Entities and the rest of your system, and if you don't need to reuse your Entities anywhere else outside your application, you don't need the extra effort and/or complexity involved in isolating them (assuming that their state, if existent, is well encapsulated). Don't add complexity where you don't need it :)
- be tested with the Interactors
You guess it - depends on your domain. If you have specific code in your Entities that you want to make sure works, sure, unit test it. However, you should not refrain from testing your Interactors along with your Entities because 1) integration tests are nice, 2) interactors are pretty useless if they don't work well with your Entities, so you might as well make sure of that and 3) since you'll probably mock out repositories and mappers, you'll get a good feeling of how your robust your whole domain layer is.
Long story short, as long as you understand the context of the problem you're solving, you don't need to bother that much with how you apply clean architecture. Use it as a guide, of course, but do it in a way that feels right or makes sense to you, learn from it, and refactor it later if needed.