I keep coming back to one thing about off-by-one bugs: they survive review precisely because they look intentional. A <= where you wanted <, an index that starts at one, a slice that trims the first element. Every one of those is a thing the author meant to type. The reviewer sees a deliberate choice and assumes it was the right one, because nobody writes a slice by accident.
Compare that with a genuine slip, a missing return or an unclosed bracket. Those look wrong on sight, and we catch them in seconds. The fencepost error reads as a decision, so we read straight past it. We're good at spotting code that looks broken and poor at spotting code that looks fine and is broken.
The only thing that reliably catches them is tracing data by hand. Not reading the loop and nodding, but taking two or three records that span the boundary and walking them through. It's tedious and it feels beneath you, and it is the exact muscle that off-by-one errors are built to defeat. So when a diff touches a range or an index, I trace the edge case on paper before I approve. It has saved me twice this year already, which is two more times than my pride would like to admit.