There is more than one way to shave a cat.
In an ideal organization which has a good testing process, and where only experienced developers work who regularly write unit tests, you can leave verification of correctness fully to the authors and dedicated testers. Here PRs can be restricted to verify if there are enough (and enough of the right) unit tests, if the responsibilities between components haven't been compromised, or if a certain change should be refactored.
However, not every organization works this way. If you want to achieve a certain level of quality, someone in your organization has to do double checks and tests. Moreover, if a dev is reading and understanding some PR, they may find potential issues in the code which are unlikely to be found by a tester who treats the code just as black-box. I think it would be inefficient to ignore such issues, sweep them under the rug and just hope that a tester or the author will find the same issue by chance as well.
Of course, when this case occurs, in some organizations the reviewer may be able to ask the author of the PR to write an additional unit test to proof their code works. Or the reviewer may be able to give the tester a hint what they shall test specifically. But in some organizations, the reviewer must be the one who brings proof to the author that the issue they saw in code is a real one (by presenting some test case, manual or automated).
So in short, this is not a black-and-white situation - at the end of the day, you have to work out with your team what works best for your organization, how much testing shall be done as part of the review process and who will take the responsibility for correctness in which case. But what surely not works is saying to them "testing is not part of the PR process" and just hope that someone else will do it.