I prefer the people who only comment when they have something useful to say. Either way the responsibility for the correctness is with the code author, not the reviewer. Writing whatever and hoping for your coworkers to correct it is equivalent to asking them to do your job.
In my experience there is a scale of how thorough the review can be. The scale is continuous, but most reviews fall into one of three buckets: informational "hey this is what I am doing", light guidance "hey can you check out broad outlines without getting bogged down in details", and coauthors aka "one person writes the code, but all are responsible for the outcome".
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.
They're not your fault, they're at most your responsibility. You should be paid triple what your coworkers earn if you're willing to accept fault for what they produce.
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?
I can never claim I can find all the bugs, I’m not even that smart. Thus I can comment on style, overall compatibility with existing mechanisms. Ask/remind which tests were run.
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.
