feat: support user-delegated identity for sandbox token exchange #4599

User Story

As an OpenShell workspace admin, I want to configure a provider that lets sandbox creators authorize access to backend services on their behalf. When a sandbox makes a request, I want a compatible token service to issue a token that identifies both the delegating user and the specific sandbox, so the backend can authorize and audit requests using both identities.

Problem Statement

OpenShell's existing token_exchange flow can use a subject token stored as a provider credential. That token must be maintained separately and does not express a creator's time-limited authorization for a particular sandbox. Workspace admins need a way to offer on-behalf-of access while leaving the decision to delegate with the sandbox creator.

This follows the token-exchange work in #1987 and focuses on sandbox-scoped user delegation.

Impact / Why This Matters

Without delegated identity, users or administrators must provision and replace subject credentials separately from sandbox creation. Backend services also need a reliable way to distinguish requests made by different sandboxes on behalf of the same user.

Proposed Design

A workspace admin configures a token-exchange provider to use sandbox delegated identity as its subject-token source. A creator opts in when creating a sandbox and chooses a delegation duration, subject to a gateway maximum. OpenShell obtains and manages a separate OIDC authorization for that user and presents the user's access token during exchange. The sandbox authenticates to the token service with its own SPIFFE identity.

The token service determines the claims in the final backend token. A compatible service can use the user subject and sandbox identity presented through the exchange to issue a token carrying both identities. OpenShell does not guarantee that every token service will do so.

The creator can inspect, extend, or withdraw the sandbox's delegation. Administrators can inspect and revoke gateway-held delegated credentials.

Suggested UX

openshell sandbox create \
  --provider protected-services \
  --use-my-identity-for=8h

openshell sandbox delegated-identity status my-sandbox
openshell sandbox delegated-identity extend my-sandbox --for=24h
openshell sandbox delegated-identity withdraw my-sandbox

Acceptance Criteria

• A workspace admin can configure a token-exchange provider to use sandbox delegated identity.
• A sandbox creator can explicitly authorize delegation for a duration within the gateway limit.
• The exchange presents the creator's delegated identity and authenticates the specific sandbox to the token service.
• With a compatible token service, a backend can attribute a request to both the delegating user and the sandbox, and distinguish two sandboxes created by the same user.
• The creator can inspect, extend, and withdraw the sandbox delegation; expiry, withdrawal, and credential revocation prevent new authorized exchanges.
• Delegated credentials remain separate from the creator's normal CLI login and can be inspected or revoked by platform admins.
• Documentation states the token service requirements and explains that final token claims depend on that service.

Alternatives Considered

A provider credential can hold a user access token for exchange, but it requires separate replacement when the token expires and provides no sandbox-specific delegation window. Using only the sandbox's workload identity identifies the sandbox but does not establish which user authorized it to act on their behalf.