Deleted-resource 404s bypass the `resource_not_found` rewrite; `service get <name>` gets a raw API error

## 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 plain 404 for well-formed resource/org UUIDs. [client.rs:466](https://github.com/ClickHouse/clickhousectl/blob/d2c37f814fff53fe68d636e34103e2d0550bf84d/crates/clickhousectl/src/cloud/client.rs#L466) only matches typed status 400. Extend appropriate lookup boundaries using typed HTTP status; do not classify failures from message prefixes. Distinguish missing resource from missing subresource or wrong organization. Name lookup support is optional new functionality, not necessary to improve the ID diagnostic.

---

## 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 two most common wrong-identifier cases get the least help.

README promises that reading a service/Postgres/org by an identifier that resolves to nothing reports `No such : (organization )…` with the stable code `resource_not_found` under `--json`. That fires for a never-existing UUID (API 400) but not for a real, previously valid ID that has been deleted (API 404):

```sh
clickhousectl cloud postgres get 00000000-0000-0000-0000-000000000000
# {"error":{"code":"resource_not_found","message":"No such Postgres service: … The API rejected the identifier: BAD_REQUEST: …","command":"…"}}
clickhousectl cloud postgres get "$DELETED_ID" # also: postgres delete, service delete, query-endpoint get
# Error: NOT_FOUND: Not Found (plain text, also in JSON mode)
```

Cause: `ResourceLookup::rejected_well_formed_ids` gates on `status: 400` only, and the org-scope suffix in `convert_error_message` requires the message to be exactly `NOT_FOUND`/`NOT FOUND`, while the API sends `NOT_FOUND: Not Found`.

Related: passing a *name* where an id is expected — the most likely user mistake, and something `service query --name` accepts — gets the rawest error of all:

```sh
clickhousectl cloud service get qa-svc-6c38
# Error: BAD_REQUEST: Invalid service id
```

Suggested: extend the lookup rewrite to 404 (well-formed-UUID discriminator still applies) and use a prefix match; when the argument is not UUID-shaped, say "expected a service ID; find it with `cloud service list`, or use `cloud service query --name`" (or accept a name in `get`).

Start at crates/clickhousectl/src/cloud/client.rs:466 and trace ResourceLookup::rejected_well_formed_ids and convert_error_message. Reproduce the documented get commands, checking typed HTTP status and the API's NOT_FOUND: Not Found response. Done means deleted resources receive the documented resource_not_found diagnostic without changing the optional name-lookup scope.

Written by the indexing model from the issue text.