[PG19] pg_upgrade from <= 18 loses the newest multixid if its members end at offset wraparound

Hello

I/Claude found another corner case in the multixact offset conversion,
not covered by the issues in Noah's thread [1].

In 18 and below if the members of the newest multixid end exactly at
2^32 the shutdown checkpoint stores NextMultiOffset = 0, and the
server handles this scenario properly.

But PG19 after the upgrade doesn't:

select count(*) from t;
ERROR: MultiXact 1 has invalid offset
vacuum freeze t;
ERROR: MultiXact 1 has invalid offset
CONTEXT: while scanning block 0 offset 1 of relation "public.t"

pg_upgrade --check doesn't notice anything.

Reproducing it on an 18 cluster:

pg_resetwal -O 4294967294 old
# create the zeroed members segment for that offset (14078)
create table t(id int primary key, v int); insert into t values (1,0);
-- session 1
begin; select 1 from t where id = 1 for key share;
-- session 2
update t set v = 1 where id = 1;
-- session 1
commit;

then stop the server and upgrade it.

This needs the last multixid before the upgrade to end exactly at the
boundary, so it is definitely a corner case.

The attached patch moves the zero check into the branch that reads the
next multixid's slot, matching what the server does. The existing
length calculation already handles the wrap, since both offsets are
uint32.

It also adds a scenario to 007_multixact_conversion.pl (only runs with
oldinstall set to a pre-19 installation, like the wraparound one).

[1]: https://www.postgresql.org/message-id/20260827231757.78.noahmisch%40microsoft.com