Make existing ClickPipes metrics and error diagnostics discoverable

## 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 blanket “no metrics/errors from the CLI” claim is incorrect. Official docs publish ClickPipes metrics through the service Prometheus endpoint, and cloud service prometheus already wraps it. Docs also describe system.clickpipes_log error reporting. Document these existing routes first; a dedicated per-pipe command is an optional feature. Do not mark the whole issue API-blocked merely because the ClickPipe model has no metric fields. No live scrape was performed in this review.

---

## 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 (feature gap); may be blocked on the API.

The `ClickPipe` model exposes `createdAt, destination, fieldMappings, id, name, scaling, serviceId, settings, source, state, updatedAt`. There is no rows-ingested, bytes, replication lag, last error or failure reason, and no `clickpipe metrics`/`logs`/`errors` subcommand. If a pipe fails, the entire diagnostic surface from the CLI is the string `Failed`. During the sweep the only way to know whether the S3 pipe ingested anything, or whether CDC was keeping up, was `cloud service query --id … -q "SELECT count() FROM …"` against the destination table.

Ask: if the ClickPipes API exposes metrics/errors, surface them; if it does not, say so in the `clickpipe` CONTEXT block and point at the console, because agents will look for it. Mark `blocked` if the answer is "API does not have it".

Start with the official ClickPipes metrics documentation, the cloud service prometheus route, and the system.clickpipes_log error-reporting documentation. Check the clickpipe CONTEXT block for how existing routes should be surfaced; done means those routes are discoverable without assuming a new per-pipe command, subject to the plan in #757.

Written by the indexing model from the issue text.