BUG #19868: pg_resetwal prints uint32 WAL segment size as -1 bytes

The following bug has been logged on the website:

Bug reference: 19868
Logged by: Milo
Email address: 1548140642(at)qq(dot)com
PostgreSQL version: 18.6
Operating system: Linux/amd64
Description:

When pg_resetwal -n reads a damaged pg_control whose uint32 xlog_seg_size
field contains 4294967295, its invalid-WAL-segment-size warning prints "-1
bytes". The diagnostic should preserve the unsigned field value and print
"4294967295 bytes".

How to repeat:

On the tested PostgreSQL 18 x86-64 build, save the following as
reproducer.sh:

```sh
#!/bin/sh
set -eu

d=$(mktemp -d)
trap 'rm -rf "$d"' EXIT
mkdir -p "$d/global" "$d/pg_wal"
cp "$PGDATA/global/pg_control" "$d/global/pg_control"
printf '18\n' > "$d/PG_VERSION"
printf '\377\377\377\377' |
dd of="$d/global/pg_control" bs=1 seek=228 conv=notrunc 2>/dev/null
/usr/lib/postgresql/18/bin/pg_resetwal -n -D "$d" 2>&1 || true
```

Run it with PGDATA naming a PostgreSQL 18 data directory:

```sh
sh reproducer.sh
```

The script modifies only the isolated copy. The relevant output is:

```
pg_resetwal: warning: pg_control exists but has invalid CRC; proceed with
caution
pg_resetwal: warning: pg_control specifies invalid WAL segment size (-1
bytes); proceed with caution
```

For this build, offset 228 is the xlog_seg_size field. The four bytes
written there represent UINT32_MAX, or 4294967295, so the second warning
renders the unsigned value as signed.

The issue was reproduced on PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2),
64-bit, on Linux/amd64. Source inspection of PostgreSQL 20devel also shows
that the uint32 ControlFile.xlog_seg_size value is passed to ngettext format
strings using %d; PostgreSQL 20devel was not tested in a recorded runtime
execution. This occurs when pg_resetwal diagnoses an invalid WAL segment
size stored in a damaged control file.