pg_upgrade stores an invalid datminmxid/relminmxid when the old cluster's newest multixact is 0xFFFFFFFF

Hi,

While testing pg_upgrade's multixact conversion around commit 2323f03,
I ran into an adjacent, pre-existing issue.

When the old cluster's newest multixact is 0xFFFFFFFF, its checkpoint
has NextMultiXactId = 0. copy_xact_xlog_xid() maps that to
FirstMultiXactId for pg_resetwal, but set_frozenxids() writes the raw 0
into pg_database.datminmxid and pg_class.relminmxid (the code dates to
a61daa14d56, 2014).

The effect:
- on assert-enabled builds, VACUUM fails Assert(MultiXactIdIsValid(...));
- otherwise template0 keeps datminmxid = 0 (mxid_age 2147483647) and
multixact truncation is skipped ("cannot truncate up to MultiXact 0
... skipping truncation") until autovacuum vacuums template0 -- which
it does within ~60 s by default, but never with autovacuum = off.

19's new oldestMultiXid consistency check does not catch it: it uses
modular arithmetic, so 0 "follows" 0xFFFFFFFF and passes. It
reproduces with pg_upgrade 18 and master.

The attached patch applies the same adjustment in set_frozenxids(), not
in controldata.c: the raw nextMulti = 0 is still needed so the multixact
reader sees that 0xFFFFFFFF is the newest multixid -- the case 2323f03
fixed. It also adds a case to t/007_multixact_conversion.pl.

Measured on cassert builds from 14..18 across 8 offset/multixid
wraparound boundaries (40 upgrades, plus --link from 18): with the fix,
no invalid datminmxid/relminmxid and no other datminmxid change (only
template0's 0 -> 1 in the 8 affected upgrades); without it, VACUUM traps
and the two new test checks fail. check-world passes.

So the severity is low with the default autovacuum, persistent with
autovacuum off, and a hard failure on assert-enabled builds.

Regards,
Manu