feat(examples): add a Jupyter sandbox example #2252

Problem Statement

Users need a concrete Python example that demonstrates how to launch one OpenShell sandbox with a configurable OCI image and policy, expose Jupyter as an OpenShell service, and submit work to a kernel through the Jupyter protocol. Existing examples do not show this lifecycle or the current boundaries of the Python SDK.

Proposed Design

Add an examples/jupyter-sandbox directory containing:

• A JupyterSandbox context manager that uses SandboxClient for gateway health, sandbox creation, readiness, command execution over stdin, deletion, and deletion confirmation.
• A plain demo.py script with edit-in-place constants for the image, policy, name, gateway, and submitted Python code.
• A pinned Jupyter-ready Dockerfile and a restrictive policy that denies outbound network access.
• Documentation for building the image, running python demo.py, and understanding the REST and WebSocket kernel execution flow, cleanup, and token handling.

The sandbox starts Jupyter on loopback, exposes port 8888 as a named jupyter OpenShell service, receives a unique Jupyter token through sandbox exec stdin, creates a kernel through the exposed REST API, submits an execute_request over the exposed WebSocket API, and is removed when the context exits. Until service CRUD is public in the Python SDK, the example uses a narrow openshell service CLI adapter only for expose and delete.

The documentation also proposes the missing Python SDK surface: public service CRUD, public sandbox configuration models, canonical policy YAML loading, and Dockerfile or build-directory image preparation.

Alternatives Considered

• A shell-only example would not demonstrate the requested Python SDK lifecycle.
• A fleet abstraction adds composition surface before the single-sandbox lifecycle is clear; this example intentionally starts with one sandbox.
• Calling private gRPC stubs for service exposure would hide the SDK gap and couple the example more tightly to internal generated APIs.
• Reimplementing Dockerfile builds in the example would duplicate CLI behavior; requiring a prepared OCI image keeps sandbox management focused on the SDK.

Agent Investigation

• Verified SandboxClient supports active-gateway discovery, health, create, wait_ready, exec with stdin, delete, and wait_deleted.
• Verified the public Python SDK does not currently expose service CRUD methods.
• Verified sandbox creation accepts protobuf SandboxSpec values, but the generated spec and policy models live under the private openshell._proto package.
• Verified the CLI policy loader and Dockerfile source resolver do not have Python SDK equivalents.
• Searched open and closed issues for a matching Jupyter sandbox proposal and found no duplicate.

Checklist

• I have reviewed existing issues and the architecture docs
• This is a design proposal, not a please build this request