feat(api-keys): show a simple "Last used" timestamp per API key (lighter alternative to #380)

[cristim]

Summary

Follow-up from #380 (closed without merging).

PR #380 added a heavyweight usage-stats system to API keys: a lifetime counter + a rolling-24h counter + a 3-tile summary card + a "Most active (24h)" top-3 list + per-row Requests (24h) and Requests (total) columns + a dedicated GET /api/api-keys/usage-stats endpoint + a migration for two counters and a window-start timestamp.

Per @cristim on the PR (closing comment, 2026-05-19):

I don't think these stats are valuable, we should at most update a "Last used" timestamp of the API keys, not keeping such detailed stats.

This issue tracks the lighter alternative: just a single last_used_at TIMESTAMPTZ column, updated on each authenticated API-key use, surfaced as one column in the Admin → API Keys table.

What this issue is

• One new column on api_keys: last_used_at TIMESTAMPTZ NULL
• On every successful API-key authentication, async update last_used_at = NOW() for that key — no counters, no rolling window, no separate timestamp tracking
• One new column in the Admin → API Keys UI: "Last used" — render as a relative time (e.g. "2 hours ago", "—" when null)
• Sort the table by last_used_at DESC NULLS LAST by default? Optional; can stay as-is

What this issue is NOT

• Not the lifetime counter from feat(api+frontend/admin): surface API key usage stats (closes #344 deferred) #380
• Not the rolling-24h counter from feat(api+frontend/admin): surface API key usage stats (closes #344 deferred) #380
• Not the summary card with totals
• Not the "Most active (24h)" top-3 list
• Not a dedicated /api/api-keys/usage-stats endpoint — the timestamp comes back as part of the existing GET /api/api-keys response
• Not historical time-series, IP, or endpoint tracking (deferred items mentioned in feat(api+frontend/admin): surface API key usage stats (closes #344 deferred) #380's "Scope" section also out of scope here)

Acceptance criteria

• Migration adds last_used_at TIMESTAMPTZ NULL to api_keys (and the corresponding .down.sql drops it)
• UserAPIKey / APIKeyInfo types gain a single LastUsedAt *time.Time field
• ValidateUserAPIKey async-updates the column on successful validation (single UPDATE statement; no read-then-write); failures during the update log but don't impact the request path
• Existing GET /api/api-keys returns the new field (no new endpoint)
• Admin → API Keys frontend renders a "Last used" column with relative-time formatting and "—" for null
• Tests cover: column appears in API response, async update fires on success but not failure, frontend renders null vs populated, time formatting

Implementation notes

The PR #380 branch (feat/admin-apikeys-usage-stats) is closed but the worktree exists at ~/.worktrees/CUDly/apikeys-usage and could be partially salvaged — keep the migration shape, the RecordAPIKeyUsage async pattern, and the ValidateUserAPIKey async-trigger; delete the counter logic, the stats endpoint, the summary card, and the top-3 list.

Cross-references

• Supersedes the still-open intent behind feat(api+frontend/admin): surface API key usage stats (closes #344 deferred) #380 (closed)
• Original parent: feat(frontend): UI revamp — restructure IA + visual reskin to action-center pattern #340 / feat(frontend): UI revamp phase 2 — drawer + skeletons + global filters + popover chips #344 (deferred "API keys usage stats" sub-task)

[cristim]

Per project rule §1a (reuse before writing), checked the codebase before implementing — every acceptance criterion in this issue is already satisfied on feat/multicloud-web-frontend (HEAD 87070ada2). The column predates PR #380 — it was in the initial schema, so closing #380 didn't touch it.

Evidence per acceptance criterion:

Criterion	Where	Status
last_used_at TIMESTAMPTZ NULL on api_keys	internal/database/postgres/migrations/000001_initial_schema.up.sql:202	✅ already there (no new migration needed)
LastUsedAt *time.Time on domain types	internal/auth/types.go (and OpenAPI APIKeyInfo at internal/api/openapi.yaml:1714)	✅
Async UPDATE on successful validation	internal/auth/service_apikeys.go:278-285 — ValidateUserAPIKey spawns a goroutine with a detached context.WithTimeout(5s), calls UpdateLastUsed → store.UpdateAPIKeyLastUsed. Logs and swallows failures.	✅
Single UPDATE (no read-then-write)	internal/auth/store_postgres.go:746-749 — UPDATE api_keys SET last_used_at = NOW() WHERE id = $1	✅
Existing GET /api/api-keys returns the field	last_used_at in APIKeyInfo schema (internal/api/openapi.yaml:1714), no separate endpoint	✅
"Last Used" column in Admin → API Keys UI	frontend/src/apikeys.ts:88 renders formatDateTime(key.last_used_at) with a <span class="text-muted">Never</span> fallback; column header at apikeys.ts:65	✅
Tests for async update success + failure	internal/auth/service_apikeys_test.go:638-664 (TestService_UpdateLastUsed) + :495 (.Maybe() mock on the validation happy-path test)	✅
Frontend tests covering null vs populated	frontend/src/__tests__/apikeys.test.ts:73, :253, :917	✅

Two cosmetic deltas vs the issue body — not blockers, calling them out for transparency:

1. Null state shows Never (not —). Never is arguably clearer to end users; recommend leaving as-is.
2. Populated timestamps render via formatDateTime (absolute), not relative. If a relative-time render is wanted, that's a small follow-up I'd file separately.

Recommend closing as completed. Happy to file the relative-time tweak as a tiny follow-up if you want it.