`sslmode=prefere` surface misleading "no encryption" error when using a wrong password

Nobody has claimed this yet.

## Summary
When connecting with the default `sslmode=prefere` to a PostreSQL server that requires SSL (e.g. Amazon RDS with their default force_ssl=1), asyncpg reports:
```
asyncpg.exceptions.InvalidAuthorizationSpecificationError:
no pg_hba.conf entry for host "...", user "...", database "...", no encryption
```
The "no encryption" message points at an SSL/`pg_hba.conf` problem, when the actual issue is simply wrong credentials. This can send users on a lengthy debugging detour (so I heard).

## Steps to reproduce

1. Set up a PostgreSQL instance that requires SSL (e.g. Amazon RDS with `rds.force_ssl=1`).
2. Attempt to connect with `sslmode=prefer` (or rely on the default) using an **incorrect password**.

**Expected:** An error indicating password authentication failed (or at least something that points toward credentials). **Actual:** `no pg_hba.conf entry ... no encryption`

## Analysis
(Disclaimer: First glance at the asyncpg code and no Python dev)
I believe what's happening is the following
The retry logic in `_connect_addr` / `__connect_addr` (`connect_utils.py`) does the following for `sslmode=prefer`:

1. **First attempt** — connects with SSL. The TLS handshake succeeds, but authentication fails, raising `InvalidAuthorizationSpecificationError`. The exact server message from this first attempt is never surfaced to the user.
2. The exception handler at the `except InvalidAuthorizationSpecificationError` block checks `retry and params.sslmode == SSLMode.prefer and pr.is_ssl` — all `True` — and raises `_RetryConnectSignal`.
3. **Second attempt** — connects **without SSL**. The server, which requires SSL, rejects the plaintext connection with the `pg_hba.conf` / "no encryption" error. This is the only error the user sees.

Is there a way to safely distinguish between both cases and do not attempt to retry when the first attempt fails because of a wrong password? Or otherwise: Can we preserve the error message and raise both?

Start by reproducing the failure against a PostgreSQL server requiring SSL with an incorrect password, then inspect _connect_addr/__connect_addr and the retry handling in connect_utils.py. Done means the first authentication failure is preserved or the retry no longer replaces it with the misleading "no encryption" error.

Written by the indexing model from the issue text.