More partition pruning bugs with multi-column RANGE partitions

There is still a pending bug report in [1] about the DEFAULT partition
still being pruned incorrectly in some cases. This one isn't the same
issue, but I did find this one as a result of looking into Ewan's
report (which I'm still looking at).

This is the reproducer:

create table mc2ap (a int, b int) partition by range (a, b);
create table mc2ap1 partition of mc2ap for values from (1, 4) to (1, 7);
create table mc2ap2 partition of mc2ap for values from (1, 7) to (3, 8);
create table mc2ap3 partition of mc2ap for values from (4, 8) to (6, 9);
create table mc2ap_def partition of mc2ap default;

insert into mc2ap values(1,7);

explain select * from mc2ap where a <= 1;

set enable_partition_pruning=1;
select * from mc2ap where a <= 1; -- 0 rows (!)
set enable_partition_pruning=0;
select * from mc2ap where a <= 1; -- 1 row

mc2ap2 gets pruned by mistake due to an incorrectly coded loop bound.
In this scenario, before the loop, off == 0, so we never perform any
loops to look for other matching bounds. I've moved the condition
check for the loop until after nextoff has been set (according to the
inclusive variable) and breaking out the loop if nextoff is out of
bounds.

There is another similar loop in the BTGreaterStrategyNumber case. I
didn't change that one as I can't find anything wrong with it.

This problem was found using a fuzz testing script I asked Claude Code
to write. See attached.

\i partprune_fuzz.sql
SELECT * FROM pp_fuzz.regression_cases();
CALL pp_fuzz.run(100000); -- about 30 mins of processing
SELECT * FROM pp_fuzz.report();

It'll still find mismatches after applying this attached patch, but
shouldn't if you apply the fix in [1]. If it does, then there are yet
more bugs.

David

[1] https://postgr.es/m/CAON2xHO=sqdqp=z8zWkybnWp0AuvefnAi2ez2vOYWrhXB6hHWQ@mail.gmail.com