“Don’t be condescending” seems like generally applicable advice. But IMO, sometimes you just know something the code submitter doesn’t (or vise versa) and discussing that can be useful. And i think that’s pretty much teaching!
"Do [X]"
Now I write:
"I see [problem Y], consider making [change X] to improve it"
If the reviewee agrees then the change is easy and straightforward to make, but if they're unconvinced then the phrasing invites a dialog.
Or if I think I see a bug, I'll phrase it like:
"I think there's a bug here, how does this method behave if foo is null and bar is the empty string? I think we'd throw a null pointer error. Recommend adding a test for that case"
Clear, actionable, refutable
That's wisdom, and a clear way to make everyone around you better.
I'd add that being humble should also play a role. We have tastes and insights and preferences, and it's not productive to block PRs because of subjective, non-critical aspects. A working CICD pipeline lowers the cost of pushing a change, this we can always revisit things. It's far more important to have a team that trusts each other and feels confident to push changes fast than it is to have gatekeepers whose role ends up being one of needlessly putting breaks on a team for no justifiable reason.