Hi sikonium,
I will try to give you a thorough explanation to the ssh configuration and the need for a seperate gitea user.
First of all: The user running gitea, the RUN_USER from app.ini and the ssh user are all the same.
The RUN_USER configuration just tells gitea that it should promote this user for its ssh clone urls as users have to connect by this special user to the server.
The only reason for this is that this user has a special ssh configuration in his authorized_keys file.
This configuration prevents users from accessing any other part on the system besides git related ones from gitea! This is especially important for security!
Because you used your own user instead of a separate one gitea only appended the public key and other vital parts in the authorized_keys file, which means your manually imported public key is on top. And that’s the problem here.
So what happens if you clone with your user is that the ssh server is granted permission to access the server because of your manually imported key and it doesn’t get to the line written by gitea.
So gitea is left out of the process.
For that reason your path behind the colon doesn’t work as gitea would be responsible for extracting the actual user of the connection and the repository bath.
But you don’t get an alert either as you obviously have established an ssh connection with your server.
The important part here to remember that not the ssh user is used to map the author of a commit but the public key added via gitea and the maintained authorized_keys file.
Also IMHO it would be insane to create a system user for each gitea user 
To come to an end:
Use your MYUSER to access the server normally and create/use a separate user, favorably git for gitea.
After that you should clean up the authorized_keys file from the user MYUSER.
Best regards
daviian