Post-Hoc Testing is an Anti-Pattern
You have succinctly described the use case for test-first development. In general, you want to first determine if you've built the right thing. Then you need to determine if you've built the thing right!
With that said, the notion of divorcing functionality from code correctness is a false dichotomy. In order to meet a useful Definition of Done, you need to do both. More importantly, design and testing need to be done in close collaboration to avoid unnecessary hand-offs and process friction.
Treating unit and acceptance testing as post-hoc activities is often a hallmark of waterfall projects and "big, upfront planning." There are still some project domains where this is required or necessary, but if you're asking the question then your specific project probably isn't one of them.
Even if you aren't following an agile methodology per se, a well-crafted Definition of Done and a test-first approach are more likely to get you the business and technical results you need than trying to determine which post-hoc activity should precede the other. The generally-correct answer is that test design should come before coding or testing, so post-hoc anything (in whatever order) is likely to be an anti-pattern.
A Further Note on Code Reviews
When done properly, a code review is a form of validated learning. Teams that collaborate on code, or that use code discussions to capture lessons learned, are often more agile because it serves as a form of continuous improvement.
Reviewing pull requests, pair programming, or mob programming aren't really "code reviews" in the gating sense of the term. In my professional experience, teams that use code reviews for gating purposes are largely papering over a gap in their current processes or tooling, and should probably consider adding continuous integration (CI), automated testing, or a better branching model to their workflows. This is even more true when the reviews are about style or correctness. The former should be represent a working agreement within the team that's enforced by automated tools, while the latter is best addressed through executable tests.
In other words, if you're using manual code reviews as a form of acceptance testing, don't! There are more effective approaches, and the team should work together to pick the one that works best for the project.