[emupton]

Why

Console is introducing the ApplicationToken kind, scoped to a self-serve Application, closing a vulnerability where an ApplicationInstance token (e.g. a dev environment's CI token) could modify ApplicationGroups and grant itself production access. Alongside the new kind, Console adds token revocation and token expiry; this slice brings both to the CLI so compromised or stale tokens can be neutralized without deleting their audit trail.

What this PR does

• conduktor token revoke <token-uuid> calling the new POST /api/token/v1/{token-uuid}/revoke. Unlike token delete, revocation is terminal: the token stays listed with a Revoked status.
• Optional --expires-at (RFC3339) on token create admin and token create application. Validated client-side; expiresAt is only sent when the flag is set, so creating tokens against older Consoles keeps working and absent still means "never expires".
• Token struct gains ExpiresAt and Status (omitempty — older servers won't send them); token list application prints them when present.
• httpmock tests: revoke success/404, expiresAt sent when set, omitted when not, list parsing of the new fields.

Milestone: full Application-token lifecycle (mint, list, expire, revoke) from ctl — against a mock; live verification once the Console backend merges.

How to verify

go build ./... && go test ./pkg/client/ -run 'Revoke|ExpiresAt|ParsesExpiry' -v
./conduktor token create application -a myapp ci --expires-at 2027-01-01T00:00:00Z
./conduktor token revoke <uuid>

Stack: PR 2/4, on top of #156.

🤖 Generated with Claude Code