[emupton]

Why

Console is introducing a new API-token kind: the ApplicationToken, scoped to a self-serve Application (the parent resource of ApplicationInstances). It closes a vulnerability where an ApplicationInstance token — e.g. a dev environment's CI token — could modify ApplicationGroups and grant itself production access. Application-level operations now get their own token kind instead of being reachable from instance tokens.

What this PR does

First slice of CLI support — minting and listing:

• Client methods CreateApplicationToken / ListApplicationToken against the new endpoints (POST/GET /api/token/v1/application_tokens/{application-name}), mirroring the existing application-instance pair.
• New subcommands conduktor token create application -a <app> <token-name> and conduktor token list application -a <app>, with -a/--application required, matching the existing admin / application-instance commands and output format.
• Unit tests with httpmock for both methods (success + error paths).

Milestone: ctl can mint and list Application tokens (verified against a mock; live verification once the Console backend merges — it is being built in parallel against this same frozen contract).

How to verify

go build ./... && go test ./pkg/client/ -run ApplicationToken -v
./conduktor token create application --help

Stack: PR 1/4 — next slices add revoke + expiry, docs, and catalog-fetch warnings.

🤖 Generated with Claude Code