[emupton]

Optional hardening — this slice is not required for Application-token support; feel free to drop it from the stack if the tradeoff (a new warning on every run against an unreachable/older Console) isn't wanted.

Why

Console is introducing the ApplicationToken kind, scoped to a self-serve Application and deliberately less privileged than an admin token (it closes a vulnerability where an ApplicationInstance token could modify ApplicationGroups and grant itself production access). That makes restricted tokens the norm — and ctl has a failure mode that hides their misconfiguration: it fetches GET /public/docs/docs.yaml with the configured token to build its resource-kind catalog, and on ANY error it silently falls back to the embedded catalog unless -v is passed. With a restricted token, a 403 on that fetch masquerades as version skew ("unknown kind" errors) with no hint of the real cause.

What this PR does

• The catalog-fetch fallback now always prints a one-line stderr warning. HTTP errors name the status (e.g. HTTP 403 Forbidden), so permission problems no longer look like version skew. Response bodies are collapsed/truncated to keep the warning to one line.
• Still non-fatal: the embedded catalog is used exactly as before.
• Scope: console client only; the gateway client has the same silent-fallback pattern and could get the same treatment in a follow-up.

Milestone: catalog-fetch failures are visible.

How to verify

go test ./pkg/client/ -run 'OpenAPIError|OneLine' -v
CDK_BASE_URL=http://localhost:9 CDK_API_KEY=x ./conduktor get Topic   # warning names the connection failure

Stack: PR 4/4, on top of #158.

🤖 Generated with Claude Code