feat(python): include type signatures for generated gRPC calls #5039

User Story

I use the OpenShell Python SDK to manage providers and look up sandboxes from an asynchronous application. I need editor signatures and static type checking for generated RPC calls without maintaining manual request/response annotations.

Problem Statement

The Python wheel includes typed protobuf messages, but the generated gRPC callables lack explicit request and response signatures. Passing a synchronous or asynchronous channel to a generated stub does not provide reliable concrete response inference for callers.

Impact / Why This Matters

Applications must annotate each RPC callable or maintain a typed adapter to get useful completion and catch incorrect request types. These annotations duplicate the protocol and need maintenance when it changes.

Proposed Design

Ship type information for the generated gRPC bindings alongside the existing message types. Editors and type checkers should infer each RPC's request and response types and distinguish synchronous calls from async calls based on the supplied channel. Existing runtime behavior and synchronous APIs should remain unchanged.

For example, stub.GetProvider(GetProviderRequest(...), timeout=30) should produce a typed ProviderResponse with a synchronous channel. With an async channel, awaiting the same call should produce ProviderResponse. Passing DeleteProviderRequest to that method should be rejected by a type checker.

Acceptance Criteria

• The published wheel includes concrete gRPC request/response signatures for gateway and credential-driver bindings.
• Valid synchronous and asynchronous calls infer concrete response types, including streaming responses.
• Incorrect request types are rejected by static checking without caller-written RPC annotations.
• Existing RPC execution, cancellation, deadlines, and channel ownership remain unchanged.
• Documentation identifies any dependency type stubs needed for editor and type-checker support.

Alternatives Considered

Manual callable annotations and application-owned adapters work today but duplicate generated contracts. A larger handwritten client expansion is useful separately; it is unnecessary to type the existing bindings. Gateway middleware and interceptors cannot supply Python static type information.

Related work: #2960 covers a supported public raw client surface, and #1820 covers a handwritten async client. This issue is limited to generated RPC typing.