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

Chưa có ai nhận issue này.

## 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?

Bắt đầu bằng cách tái hiện lỗi khi kết nối đến một máy chủ PostgreSQL yêu cầu SSL với mật khẩu không đúng, sau đó kiểm tra _connect_addr/__connect_addr và cách xử lý việc thử lại trong connect_utils.py. Được coi là hoàn tất khi lỗi xác thực đầu tiên được giữ nguyên hoặc lần thử lại không còn thay thế nó bằng lỗi gây hiểu nhầm "no encryption".

Do mô hình lập chỉ mục viết ra từ nội dung của issue.