API key rotation and expiry

Problem

Once a user mints an API key via the key-manager UI, the key is valid forever. There is no mechanism to:

• Set an expiry at creation time
• Force rotation on a schedule
• Detect and revoke stale keys (e.g. unused for N days)
• Re-issue keys with the same client identity but a fresh secret

Combined with #55 (audit-driven revocation when group membership lapses), this is the other half of the credential-lifecycle story. Today, a key issued to a contractor or a one-off integration lives on indefinitely unless the user (or an admin) goes back to the UI and explicitly revokes it.

Proposal

1. Optional expiry at key-creation time. UI surface: an "expires after" picker (default: never, options: 30 days / 90 days / 1 year / never). Stored in KeyInfo.ExpiresAt in the metadata ConfigMap. Envoy doesn't enforce expiry on apiKeyAuth, so enforcement happens by:

   • The key-manager periodically scanning all keys and removing expired ones from the Secret (and pruning the ConfigMap row).
   • The same loop that #55's audit will run.

2. Last-used tracking so unused-key revocation has data to act on. Two options:

   • Wire EG access logs through a side process that updates KeyInfo.LastUsedAt. Higher fidelity, more moving parts.
   • Skip last-used tracking for v1 and rely on explicit expiry only. Simpler.

3. Rotation flow in the UI: "rotate this key" generates a new secret value bound to the same clientID, returns it once, and invalidates the old secret on the next reconcile. The clientID stays the same so callers updating the secret don't have to change their identity.

Out of scope

• Anything resembling JWT-style short-lived credentials. The external endpoint is API-key auth by design (LLM clients want long-lived bearer tokens). This issue is just about making the key lifecycle survivable.

Test plan

• Create a key with 1-day expiry, simulate the time advance, confirm the key-manager prunes it.
• Rotate a key, confirm the old secret stops working and the new one works under the same clientID.
• Confirm ListKeys reflects expiry/rotation state.

Start by tracing the key-manager UI, KeyInfo metadata in the ConfigMap, Secret reconciliation, and the ListKeys path. Clarify whether v1 includes last-used tracking before implementing expiry and rotation. Done means expiry pruning, same-clientID rotation, old-secret invalidation, and the listed test-plan behavior are covered.