PasswordMessage passed to postgres instance returns 'insufficient data left in message'

**Describe the bug**
When proxying messages from the psql cli to a postgres instance (using a `Backend` for the client and a `Frontend` for the DB, I can successfully pass most messages back and forth until it gets to the `PasswordMessage`. When I proxy that to the database, it returns the error:
FATAL 08P01 insufficient data left in message

**To Reproduce**
Steps to reproduce the behavior:

If possible, please provide runnable example such as:

```go
package main

# the code has a channel of the messages going back and forth, so it can keep the sequence in order.
# I'd be happy to spin up an example codebase with a working copy of the code or something, but it feels too big to drop in a bug report

switch msg := unCast.(type) {

case *pgproto3.SSLRequest:
_, err := p.clientConn.Write([]byte("N"))
if err != nil {
return err
}

case *pgproto3.StartupMessage:
p.username = msg.Parameters["user"]
p.databaseFrontend.Send(msg)
p.databaseFrontend.Flush()

case *pgproto3.AuthenticationSASL:
p.clientBackend.Send(msg)
p.clientBackend.Flush()

case *pgproto3.PasswordMessage:
p.databaseFrontend.Send(msg)
p.databaseFrontend.Flush()

case *pgproto3.ErrorResponse:
p.clientBackend.Send(msg)
p.clientBackend.Flush()

}
```

**Expected behavior**
I expect the message from the client to be received without error by the postgres database, and for the initialization handshake to continue.

**Actual behavior**
```bash
msg c->db (*pgproto3.SSLRequest): &{}
msg c->db (*pgproto3.StartupMessage): ....
msg db->c (*pgproto3.AuthenticationSASL): &{[SCRAM-SHA-256]}
msg c->db (*pgproto3.PasswordMessage): &{SCRAM-SHA-256}
msg db->c (*pgproto3.ErrorResponse): &{FATAL FATAL 08P01 insufficient data left in message %!!(MISSING)s(int32=0) %!!(MISSING)s(int32=0) pqformat.c %!!(MISSING)s(int32=531) pq_copymsgbytes map[]}
```

**Version**
- Go: go version go1.23.2 linux/amd64
- PostgreSQL: postgres:17 docker image
- pgx: github.com/jackc/pgx/v5 v5.7.1

Start with the pgproto3.PasswordMessage path and the Backend/Frontend Send and Flush calls shown in the report, then compare the forwarded message with PostgreSQL's expected wire format. Done means the PostgreSQL 17 handshake accepts the password message without the 08P01 error and continues.

Written by the indexing model from the issue text.