`cloud key create` without `--ip-allow` creates a deny-all key; human output never prints the resource id needed by `key get/update/delete`

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

Source confirms an empty default IP list and a human confirmation that prints the authentication identifier but omits the management resource ID. Deny-all behavior remains live QA evidence. Keep both identifier labels clear. Prefer explicit allowlist input or a clear warning over silently broadening access to 0.0.0.0/0. A different default is a product decision, not an automatic bug 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; the created key cannot authenticate to anything and nothing warns.

```sh
clickhousectl cloud key create --name qa-key --role-id "$ROLE"
# API key created! Name: qa-key Key ID: IufEy2PqIGWenK91tQhG Key Secret: …
clickhousectl cloud org list --api-key IufEy2PqIGWenK91tQhG --api-secret …
# Error: FORBIDDEN: IP address not allowed: 81.78.86.189
clickhousectl cloud key update "$KEY_UUID" --ip-allow 0.0.0.0/0=any # immediately fixes it
```

`ipAccessList: []` means deny-all. This is the opposite of `cloud service create`, whose README section says omitting `--ip-allow` creates an "Allow all" list, and neither `key create --help` nor the README Keys section mentions it.

Second problem in the same command: the human confirmation's "Key ID" is the *auth* key id (`--api-key`), not the resource UUID that `key get/update/delete ` require. `cloud key get IufEy2PqIGWenK91tQhG` → `BAD_REQUEST: Invalid API key id`. The UUID is only reachable via `key list --json`. `--json` does include both. Both identifiers are labelled "Key ID" in help.

Suggested: default to `0.0.0.0/0` on create to match services, or print a warning when `--ip-allow` is omitted; print the resource id in the human confirmation; disambiguate the two labels in help ("Auth key ID" vs "Resource ID").

Start by reproducing `cloud key create` without `--ip-allow`, then compare its behavior and output with `cloud service create`, `key get/update/delete`, `key list --json`, the `key create --help` text, and the README Keys section. Done means the deny-all behavior is addressed or clearly warned about, the human output exposes the resource ID, and the two identifier labels are unambiguous; the default-versus-warning choice remains a product decision.

Written by the indexing model from the issue text.