The moment when you should deviate from a particular principle/architecture, is when it becomes a greater inconvenience to follow it than to not follow it. This is because project requirements shape the architecture whether we are talking about software or actual buildings. It is okay to try and make on architecture work for every situation at first, but this is mostly so you can learn when it does not suit a given situation.
Unfortunately, I do not have the full context of where that image came from, but judging by your mention of the SRP, it looks like it is either Uncle Bob's work or something closely inspired. I think you may have made the same mistake that I, and a few thousand other developers made about the SRP. To quote Clean Architecture (the book, by Uncle Bob):
Of all of the SOLID principles, the Single Responsibility Principle
(SRP) might be the least well understood. That's likely because it has
a particularly inappropriate name. It is too easy for programmers to
hear the name and then assume it means that a module should do just
one thing.
For context, the word module does not mean Gradle Module, Uncle Bob goes on to define the word as meaning a source file (in OO we can think of a class like Controller). I will leave you to research what Uncle Bob really meant with the SRP as I simply do not use the term anymore nor like to explain it. None of that is meant as disrespect to Uncle Bob; I am very fond of his work.
Returning to the question, it is hard for me to answer without knowing more context about the Controller (does it simply handle clicks and forward them to the appropriate Interactor?). I am assuming this is an Android app, in which case I would simply combine the Controller and Presenter into a single class. This is in my opinion neither a violation of Uncle Bob's SRP (which is about separating things that change for different reasons), nor would it result in a class which has low-cohesion (which concerns what a module/class/function/source does). I realize this is partly subjective, but handling UI interactions and preparing returned back end data for a ViewModel both fit under the role of Presentation Logic of a particular GUI feature in my opinion.
Failing that, ignore what I said and what the diagram is telling you and just look at the code. Does it really solve more problems to keep them separate than apart? Act accordingly.
I don't see any sensible way to follow this diagram exactly, given the requirements you have mentioned, but here is what I would do if I really had to keep the Controller and Presenter separate:
Employ the Observer (Publisher-Subscriber) Pattern between the Controller and Presenter (or maybe the Presenter and Interactor... not what I would do but this diagram does not reflect how I typically use Interactors either). You get to keep everything loosely coupled and avoid a concrete reference (i.e. drawing an arrow) between them.
You could have a Usecase which has the sole purpose of handling a mouse click and calling back to the Presenter that it occurred. I am going to be honest, this seems like a ridiculous solution. What is the point of having an Interactor that encapsulates the business logic of incrementing a counter in the UI? Unless you saved that counter every time, it does not even seem appropriate for the term business logic to begin with.
Hopefully that helps; just trying to share my past experience in case it will help.
