Support for On-Behalf-Of credentials (OBO): which agent for who #3715

Summary

Let the egress gateway get a downstream token whose subject is the end user and whose actor (act claim) is the Substrate actor, using an on-behalf-of token exchange. Policy at the exchange can then combine both identities.

Motivation

When an actor calls an API for a user today, you pick one identity:

• The user's credential (e.g. an OAuth token injected through a credential provider). Logs and policy see the user. You can't tell which agent acted, or whether an agent was involved at all.
• The actor's identity (actor JWT or certificate). Logs and policy see actor/<atespace>/<name>, but not whom it was acting for. Today you could create one atespace per user, and so figure out the user by convention.

But neither supports policy like:

allow actor mail-agent
  to read alice's mail
  when trust domain == mycompany.prod

(actor and trust domain are the actor JWT's actorName and iss.)

The landscape is not really settled yet. RFC 8693 defines the token (user as subject, agent as actor), but there's no agreed way for an agent to request it: Entra uses its own OBO grant, Keycloak uses RFC 8693, and the IETF drafts for agent consent and delegation chains are still drafts.