Maybe these checks can be done inRenameBranch, and return different http status codes by catching errors?

Is this a blocked request?

No.
In the web UI, user can not rename branch in mirror/empty repo. So maybe it is ok to skip these checks.
But you can create a special request to do it. So I think it is better to move these checks to the functions in service level. I have also mentioned this problem in some issues/PRs. But it seems that it is acceptable in this project, so this is not a blocked request.
e.g. I can pick up a public mirror repo in Gitea.com, then I create a fake request to change the branch name or do somethings which is not expected and no checks for the web UI side, I'm not sure what will happen, but it is not LGTM.

Maybe we can put that for another PRs. This PR is focused on adding the API endpoint.

I originally found those checks in the other branch API implementations and believed it made sense to include them in here.

I do agree that this logic should be moved to the service layer. To me, the presentation layer (i.e. the API and web routes handlers) should just be concerned with presenting the response given what the service layer provides. From my experience it does look like we have sprinkled application logic into our middleware and our web/API route handlers, so it does become confusing when considering where it should be added.

But I also agree with doing this in a separate PR just to keeps our changes atomic (since I would also wan't to add service layer tests for these checks). I would be more than happy to do this once this one is merged.