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.
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?