Confirm and fix switchover acknowledgment when no standby exists

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

Retain as an upstream API investigation. Reported 200/no-op needs backend confirmation; the CLI cannot prove a swap merely from acknowledgement. Link the actual backend ticket. Keep separate from #834’s CLI surface decision and #827’s unrelated PATCH/tag backend defect.

---

## 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; silent success on a lifecycle command.

**Blocked on:** Cloud API owners changing the state endpoint's behaviour. Needs a corresponding backend ticket; tracked here so the CLI issue removing `--wait` (#834) has a pointer.

Observed on 2026-09-11 against a freshly created Postgres service (aws / eu-west-1 / c6gd.large):

```sh
clickhousectl cloud postgres switchover "$PG" # haType=none → 200, exit 0, service object echoed
clickhousectl cloud postgres update "$PG" --ha-type async # haType flips to async immediately
psql … -c "select inet_server_addr(), pg_postmaster_start_time()" # 10.24.1.228, 10:35:25
clickhousectl cloud postgres switchover "$PG" # 200, exit 0
sleep 90; psql … -c "select inet_server_addr(), pg_postmaster_start_time()" # identical node, identical postmaster
```

The OpenAPI document for the state PATCH lists only 200/400/500 and no "no standby" or "not applicable" response. Nothing in the response distinguishes "swapped", "not applicable (haType=none)" and "standby not yet ready", so a client cannot tell the user the truth without guessing about server behaviour (which #627 review explicitly rejected).

Expected: a 4xx (e.g. 409) with a discriminable message when there is no standby to switch to, and ideally a response field that identifies the new primary. Once that lands the CLI can classify it structurally like `service delete` CONFLICT (#673).

Start with the OpenAPI definition for the state PATCH and reproduce the documented switchover commands against a service with no standby and one using async HA. Confirm the backend behavior and link the corresponding backend ticket; done means the API distinguishes a real swap from no applicable standby or an unready standby without requiring the CLI to guess.

Written by the indexing model from the issue text.