With Docker unreachable, `local server list` and `local postgres client` report running Postgres instances as stopped instead of surfacing `docker_unavailable`

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

Reproduced a synthetic Postgres instance reported running:false when Docker was unreachable. [docker.rs:1014](https://github.com/ClickHouse/clickhousectl/blob/d2c37f814fff53fe68d636e34103e2d0550bf84d/crates/clickhousectl/src/local/docker.rs#L1014) converts connect errors to false, and inspect errors are likewise collapsed. Preserve the distinction between stopped/missing and unavailable/unknown through list and lifecycle callers. Not part of #783’s running-instance remove diagnostic or #815’s naming fix.

---

## 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: high; false state a user may act on.

Three Postgres containers running (confirmed with real `docker ps`):

```sh
DOCKER_HOST=tcp://127.0.0.1:1 clickhousectl local postgres client -q 'SELECT 1;'
# Error: Server 'default' is not running
DOCKER_HOST=tcp://127.0.0.1:1 clickhousectl local server list
# | default | postgres | stopped | … ← actually running
# 3 servers, 0 running
DOCKER_HOST=tcp://127.0.0.1:1 clickhousectl local postgres start --name x
# {"error":{"code":"docker_unavailable", …}} ← correct
```

`start` classifies the daemon failure; `list` and `client` swallow it and default unknown container status to "stopped". A user could conclude data is gone, or `start` an instance that is already running and hit a port clash when Docker returns.

Suggested: propagate `docker_unavailable` from the status probe (or render an explicit `unknown` status with a stderr note) in `server list` and `postgres client`/`stop`/`remove`.

Start at crates/clickhousectl/src/local/docker.rs:1014, then trace how status-probe errors reach local server list and local postgres client, stop, and remove. Reproduce with DOCKER_HOST=tcp://127.0.0.1:1 and verify that unreachable Docker is no longer shown as stopped, instead surfacing docker_unavailable or an explicit unknown status.

Written by the indexing model from the issue text.