feat(python): expose the complete gateway gRPC surface

[dhirajsb]

User Story

As a Python application developer,
I want a supported escape hatch to the generated gateway gRPC client and wire types,
so that I can use newly added OpenShell capabilities without waiting for every RPC to receive a curated Python wrapper.

Problem Statement

The Python SDK currently exposes curated sandbox, workspace, and inference-route operations, but keeps its generated OpenShellStub and protobuf modules under private attributes and the private openshell._proto package. Gateway operations such as Provider CRUD and credential rotation are therefore present in the installed wheel but do not have a supported public Python API.

This also causes API drift: adding an RPC to proto/openshell.proto does not make that operation publicly reachable in Python, while the TypeScript SDK already guarantees full gateway coverage through client.raw.

Impact / Why This Matters

Without this capability, Python applications must import private modules and access client._stub, shell out to the CLI, or wait for a curated wrapper. Private imports can break without notice and duplicate the SDK transport and authentication setup. Provider credential updates are one concrete blocked workflow, but the gap applies to every uncurated gateway RPC.

Proposed Design

Provide a documented advanced Python escape hatch equivalent in intent to the TypeScript SDK:

• A public raw client on the authenticated SandboxClient that exposes every method generated for the OpenShell gateway service.
• A public module containing the generated request and response modules needed to call it.
• Preserve the curated SDK as the preferred interface; the raw layer returns protobuf messages verbatim and does not promise ergonomic wrappers.
• Keep transport, TLS, and bearer-token handling shared with the existing client.

Acceptance Criteria

• Every RPC in the generated OpenShell gateway service is callable through a supported public Python API.
• Public imports provide the generated request and response types needed by those calls.
• Raw calls reuse the existing client channel and its TLS/OIDC configuration.
• A test detects if the public raw client drifts behind the service descriptor.
• Documentation includes an uncurated Provider update example and explains timeout and lifecycle behavior.
• Existing curated SDK APIs remain backward compatible.

Alternatives Considered

Adding typed wrappers for all RPCs at once would create a large API-design and maintenance burden, particularly for internal supervisor and callback operations. Continuing to use _stub and _proto exposes private implementation details. A small public raw floor provides immediate parity while allowing curated clients to evolve deliberately.

Agent Investigation

• Compared proto/openshell.proto with python/openshell/sandbox.py: the generated service contains substantially more RPCs than the curated Python client exposes.
• Confirmed that generated protobuf and gRPC files are already packaged in the Python wheel under openshell._proto.
• Confirmed the TypeScript SDK already documents and tests client.raw plus its public raw wire-type export.
• Searched existing issues and PRs. Python and TypeScript SDK Support #1044 established the broad Python/TypeScript SDK objective but is closed; feat(sdk): SDK acceptance scorecard and conformance tiers #2292 proposed a future conformance scorecard and is closed. No open issue or PR specifically covers a supported Python raw gateway surface.

I am available to contribute a focused implementation of this design.

Checklist

• I have reviewed existing issues and the architecture docs
• This is a design proposal, not a request for someone else to build it

[johntmyers]

I'm not opposed to this but this also seems like something we should automate: SDKs receive updates real-time with proto CRUD changes? #2565 - @drew is this something we should consider and track separately?