Document safe Postgres connection recovery and endpoint details

## Validated scope and current-PR plan — 2026-09-11

This section records the QA review and the current decision to finalize existing PRs without opening new PRs. It supersedes the proposed routing/fix suggestions in the original report below; the original observations are retained. Central plan: #757.

### Disposition

Deferred from this existing-PR finalization pass. Keep the issue open; no new PR is requested now. This is not a resolution, a severity downgrade, or a waiver of release acceptance.

### Validation and corrections

The missing connection fields are supported by current output. Preserve password non-disclosure on reads; do not promise a full password-bearing URI on replica/restore when the response contains no password. Add safe host/port/password-less URI or actionable connection guidance. Document credential inheritance once its scope is confirmed; do not assume a source’s current password always equals a historical PITR backup’s password.

---

## Original QA report

Found in the 2026-09-11 QA sweep of the combined PR stack at [`d2c37f81`](https://github.com/ClickHouse/clickhousectl/commit/d2c37f814fff53fe68d636e34103e2d0550bf84d), top PR #823, installed release build (package version still 0.4.2). Reproduced behaviour only; no implementation included.

Severity: medium; the connection string exists exactly once, in `create`'s one-shot output.

| command | returns |
|---|---|
| `create` | `password` + `connectionString` (works verbatim in psql) |
| `get` | `hostname`, `username` — no port, no URL, no password (by design) |
| `reset-password --generate` | `{"password": "…"}` and nothing else |
| `read-replica create` | no password, no connection string |
| `restore` | no password, no connection string |

Recovery path when the `create` output is lost: `get` → `reset-password` → hand-assemble `postgres://user:pw@host:5432/postgres?sslmode=require`, URL-encoding the password yourself; `5432` appears nowhere in `get` output in either mode.

Verified empirically that a read replica and a PITR restore both accept the *source* password (replica: `pg_is_in_recovery()=t`; restore: `f`, data present). Neither help nor README says so, and the `postgres` parent CONTEXT ("Credentials come only from `create` and `reset-password`") reads as "you must rotate the password on a restored instance", pushing users into an unnecessary rotation during a DR drill.

Suggested: add `port` and a password-less `connectionString` to `get`; return a full `connectionString` from `reset-password`, `read-replica create` and `restore`; one help line on replica/restore saying credentials are inherited from the source.

Start with the CLI help and README sections for get, reset-password, read-replica create, and restore, then compare them with the observed outputs described here. Document safe recovery details, password non-disclosure, connection fields, and source-credential inheritance without promising unavailable passwords; confirm the wording against the plan in #757.

Written by the indexing model from the issue text.