Surface the acting API client in audit/activity data (CLI + API) — API-created assets all attribute to the workspace service account

[mattpalmer-persefoni]

We're building recipes through the wk CLI (and Claude Code driving it) and gave each developer their own Developer API client, for independent revocation and project/environment scoping. We realize the core fix here may be a platform change rather than a wk tooling change, but we're surfacing it in Labs because it directly affects being able to attribute who did what when working through the wk tools. While verifying attribution we found that three surfaces disagree about "who performed an action":

Surface	Shows for an API-created recipe
Recipe → Versions → "Modified by"	the workspace service account (identical for every developer)
Workspace Activity feed (UI)	the API client name ✅ (correctly distinguishes clients)
wk workspace audit-log and GET /api/activity_logs	user = workspace service account; details has only ip_address + user_agent; no api_client field at all

So the platform clearly knows which API client acted — the UI Activity feed shows it — but that identity isn't available anywhere automation or governance can consume it.

Two asks

1. CLI (small fidelity fix): wk workspace audit-log --json drops the resource and workspace objects that GET /api/activity_logs actually returns — its output only keeps id / event_type / timestamp / user / details. Please pass those through so the CLI output matches the API response.

2. API / platform (the real one): expose the acting API client (id + name) in /api/activity_logs (the UI already resolves it), and ideally reflect it in recipe version history — so per-developer API clients yield per-developer traceability outside the UI.

Reproduction

1. Create two Developer API clients in the same workspace.
2. Create a recipe with each (e.g. wk recipes import <file> --folder <id>).
3. The recipe's "Modified by" and the /api/activity_logs user are identical (the workspace service account) for both — only the UI Activity feed tells the two clients apart.

Why it matters

Issuing one API client per developer is a security best practice, but today there's no machine-readable way to attribute a CLI/API-built recipe to the person (or client) that created it. Surfacing the acting client in the API — and on the asset — would close that gap.