Assuming Developers A,B,C,D of somewhat similar experience and expertise. For one month, randomly assign Developer A,B for example, as committers and C and D as reviewers:
1) Developers A and B create code and submit pull requests.
2) Developers C and D are randomly assigned as reviewers.
3) IF there is a future bug, on code that passed the review, its not up to A or B to fix it. One of the originals reviewers, ( ex C or D) are randomly assign to fix the reviewed code. NOT the original Developer.
4) Developers A and B while as committers, get a value metric on how much code passes reviews and gets committed to production.
5) As no Developer A, B, C,or D ever wants to have to fix the code of somebody else...Reviews are very thorough.
6) Next month... A and B are on the reviewers team and C and D on the committers.
Trivial stuff is easy to catch, refactoring parts I’m familiar might help with pitfalls known to me.
Still I can’t see how one can claim finding all bugs is possible.
Are you perhaps a team manager and insisting that all your team PR's go through you? Might I suggest that instead of signing off on all PR's yourself, setting up a good testing framework may help you sleep better at night?
Generally the bucket review falls in depends on code criticality, code simplicity, company culture, how much reviewer cares about the code you are changing, how much reviewer cares about you/your changes (mentorship etc.), and how tired / overwhelmed the reviewer is. It follows, that assigning reviewers that care about the code/author and not reviewing code while tired tends to produce higher quality reviews.
In the end author, reviewer, and thoroughness of the review is an engineering call. Both author and reviewers should be able to understand where they are on the scale and be able to substantiate why.