Reveal Key

The manual fallback — hand over the key, not a secret to exchange for one.

If the agent is gone (context compacted, client restarted) the person who approved can take the key themselves, once. Having them paste a secret so the agent can swap it for a key adds a round trip and no security: both are bearer credentials.

A route of its own rather than a field on approve, and that is what makes the race decidable: reveal and claim both go through mark_claimed under its SELECT … FOR UPDATE (re-read there, ZCT-806), so whichever arrives second sees the first's write. Exactly one key per request is ever live — which is a property that cannot hold if approval mints on one path and polling mints on another. Since ZCT-806 only a reveal re-issues: a poll of a request that already issued a key answers collected and revokes nothing, so this route is the last path that supersedes a live key.

Session-gated and owner-only: by now the row has a user_id, because approving is what put it there.