Maybe this is a useful way to think about it: I'd argue that doing code review for everyone on a team doesn't mean I'm a mentor to everyone on the team. I'm doing a task that is part of my job -- to coach the team on coding -- and they have to consider my comments whether they want to or not.
But if an engineer approaches me and says "in my last performance review, I was told my code isn't very well structured; can you help me?" and I walk through their code with them, then I'm mentoring. It's skill mentoring, in this case, which, as I said, has the most overlap with coaching. Same activity, but different context.
But as someone else said, this distinction isn't really the important part of what I wrote. So if people disagree on the terminology, that's just fine.
The way I think about it is that it’s coaching if you are making decisions for them about the path they should take. It works here because writing code is a fairly general skillset.
With mentoring, the crux of the problem is that you’re trying to help them navigate their specific situation. And in my experience both as a mentor and a mentee, “where are they trying to go and what do they really want?” is actually the hardest part, and it’s not something you can consistently answer because it’s their experience and you’ll never fully understand the nuances of it. You can’t lay out the path for them, you can only (try to) help them see further down the path they’re already on.
If the developer is young/new and you are reviewing their code expecting various mistakes that you can then "coach" them about, it could be part of coaching. However at other times, code review is just what you do as a second pair of eyes, you are not expecting to give coaching as a result of something you might spot, just feedback.
I wouldn't worry too much about specifying things too specifically though!
Re-reading: code review is coaching I think. Because you're asking for directed feedback, not general life advice.