TypeScript SDK: add a first-class ProviderClient

User story

As an agent-orchestrator developer, I need an idiomatic TypeScript API to create and update workspace providers so I can give each sandbox or security principal isolated, short-lived credentials through OpenShell without exposing credential plaintext to sandbox application code.

Problem statement

The generated client.raw transport provides complete typed wire-level access, but provider lifecycle and credential rotation require callers to assemble protobuf requests, preserve 64-bit version fields, validate responses, and map errors themselves. The TypeScript README consequently lists client.providers as planned.

Impact

Agent orchestrators commonly create one provider per sandbox or security principal, attach it to a sandbox, and rotate short-lived credentials through OpenShell without exposing credential plaintext to sandbox application code. This should be an idiomatic, stable SDK workflow rather than a raw-RPC integration.

The workaround couples applications to protobuf request details and leads each TypeScript consumer to recreate concurrency, validation, redaction, and error-handling behavior already curated elsewhere in the SDK. This is a focused continuation of the SDK direction tracked in #1044, which is closed.

Desired workflow

1. Connect once with OpenShellClient.connect() and use client.providers over the same authenticated transport.
2. Create or ensure a workspace provider with credentials, configuration, and expiry metadata.
3. Attach that provider to one sandbox (or include it when creating the sandbox).
4. Update the provider with a refreshed credential and optional resource-version pin.
5. Continue using the sandbox without exposing returned credential plaintext to application code.

Acceptance criteria

• Add client.providers and standalone ProviderClient.connect() using the existing authenticated/shared Connect transport.
• Curated typed domain models for provider inputs and redacted provider records.
• Provider create, get, list, update, delete, and idempotent ensure.
• Preserve uint64/int64 values as strings, validate inputs, use existing SdkError mapping, and support optimistic-concurrency resource versions.
• Document per-sandbox credential updates through OpenShell provider handling.
• Unit tests for request conversion, secret redaction, error behavior, list validation, update, and ensure.

Alternatives considered

• Continue using client.raw: complete and typed, but intentionally an advanced wire-level escape hatch rather than an idiomatic SDK API.
• Add profiles and refresh in the same change: more complete, but substantially expands the public API and review surface. A CRUD/update first slice delivers the manual credential-rotation workflow while allowing those nested clients to be designed separately.

Follow-ups

Provider profiles and automatic credential-refresh operations (configure, status, delete, and rotate) should be curated as nested clients after this reviewable first slice. They remain typed and usable through client.raw until then.

I would be happy to contribute this implementation. A focused draft PR is available at #2964 for API feedback while this RFE is triaged.

Review the existing OpenShellClient.connect() shared authenticated transport and client.raw patterns, then inspect draft PR #2964 for the proposed API direction. Verify the provider models and conversion boundaries against the acceptance criteria, including redaction, string-preserved integer values, validation, SdkError mapping, concurrency, and unit-test coverage. Done means the client providers workflow, documentation, and requested tests are complete without exposing credential plaintext.