BUG #19685: START_REPLICATION accepts an overflowing LSN component

The following bug has been logged on the website:

Bug reference: 19685
Logged by: Qifan Liu
Email address: imchifan(at)163(dot)com
PostgreSQL version: 18.6
Operating system: Linux/amd64
Description:

A logical replication command accepts the LSN 100000000/1, whose high
hexadecimal component exceeds 32 bits, and proceeds to slot or configuration
validation. Inference: the replication scanner accepts an unbounded
hexadecimal component and converts it to uint32 without enforcing the
canonical range. The verified behavior is limited to START_REPLICATION;
other source-identified LSN parsing paths were not exercised.

Impact: The replication protocol silently accepts and transforms an invalid
position instead of reporting malformed input. This creates inconsistent
validation relative to canonical pg_lsn input and may cause replication to
begin from a position different from the one supplied. Successful
replication from the transformed position was not tested, and no crash,
corruption, or security impact was observed.

Steps to reproduce
------------------
Prerequisites:
- Run against a disposable PostgreSQL instance using a role allowed to issue
replication protocol commands.

```sh
psql -X -h /tmp 'dbname=postgres replication=database' -c 'START_REPLICATION
SLOT nonexistent_slot LOGICAL 100000000/1 (proto_version '"'"'1'"'"',
publication_names '"'"'nonexistent_publication'"'"')'
```

Actual result
-------------
```text
stderr:
ERROR: replication slot "nonexistent_slot" does not exist
PostgreSQL server log:
2026-09-12 12:39:14.640 UTC [286] ERROR: replication slot
"nonexistent_slot" does not exist
2026-09-12 12:39:14.640 UTC [286] STATEMENT: START_REPLICATION SLOT
nonexistent_slot LOGICAL 100000000/1 (proto_version '1', publication_names
'nonexistent_publication')
```

Expected result
---------------
START_REPLICATION should reject the reproduced LSN 100000000/1 as out of
range before performing replication-slot or wal_level validation.

Additional information
----------------------
The issue was reproduced on PostgreSQL 20devel, PostgreSQL 18.6, and
PostgreSQL 17.11.