A use case is not a method.
A use case is not an object.
A use case is not a layer.
A use case is a story about a user, using the software, in a particular case.
So it should come as no surprise that different use cases can reuse the same code.
But maybe you watched one of the video'spaywalled where Bob makes out like a use case is part of your architecture.
Well don't worry. It's just a name for the boxes in one of his layers. He's used other names for it:
Does this mean Uncle Bob is wrong? No. The Interactor / Use Case / Application Business Rule / Oh-pick-a-name-and-stick-with-it layer is where you ignore all of the needs of your application (details) and focus on the needs of the user going through a particular use case. But this location in your code is not THE use case. The use case is the whole story from when the user clicks a button to when they see the result.
So should interactors (or whatever you want to call them) use other interactors? Well this is the rub of following DRY to the extreme. You're not allowed to put the code from
AddUserToGroup anywhere else right?
AddUserToMandatoryGroups means something different, has a different reason to want to change than
AddUserToGroup does then it's ok to give
AddUserToMandatoryGroups its own add-user code. Even if right now it's a character for character copy of the code in
AddUserToGroup. If you have good reason to think these need to be able to change independent of each other it doesn't matter if right now they look identical. Apply DRY to repeating ideas. Not code.
As for Dependency Injection, that still works fine whenever you want to decouple what from when.
Bulk shitlist = new Bulk(annoyingUsers, bannedForLifeUnit);
Register.OnIveHadAllICanTake( ()-> shitlist.send() );