feat(sdk): support create-time policy and complete resource results in Rust

The changes are in crates/openshell-sdk/src/types.rs. Start by reviewing the existing SandboxSpec and WorkspaceRef types to understand the missing fields. Examine the gRPC gateway's sandbox-create request and response structures to map the required identity, policy, and lifecycle metadata. Write tests to verify the new fields are correctly exposed in create/get results, preserving the ability to distinguish absent values from defaults.

User Story

As a Rust SDK user building deployment automation, I want to create sandboxes with an explicit policy and inspect their stored configuration and lifecycle status through SDK calls. This requires policy on image-based creation and complete resource details in create/get results.

Problem Statement

• SandboxSpec cannot accept a create-time policy. The template-based API can, but requires a named workload template.
• WorkspaceRef omits identity, resource version, and deletion metadata. SandboxRef omits the stored specification, deletion metadata, and detailed status such as startup conditions. Their conversions also replace some absent fields with defaults.

Impact / Why This Matters

Callers must construct raw gRPC requests and handle raw responses for operations the SDK otherwise supports. This adds integration code to maintain as OpenShell evolves.

Deployment automation needs these details to identify the resource it created, detect configuration drift, and distinguish readiness, deletion, and incomplete observations.

Proposed Design

Before: A Rust caller must use a raw sandbox-create request to supply policy for image-based creation. It must also use raw workspace/sandbox responses to obtain resource details omitted by the SDK.

After: The caller supplies policy through SDK image-based creation and reads identity, stored configuration, and lifecycle status directly from SDK create/get results. These operations no longer require raw request construction or a second raw GET to recover omitted fields.

Through public Rust SDK calls, a caller should be able to:

1. Create or get a workspace and retain its identity and lifecycle metadata.
2. Create a sandbox directly from an image with its intended policy supplied in the initial request.
3. Inspect the returned resource, then read it later to compare stored configuration and status with desired state.

Expose the gateway's existing capabilities and returned resource information. Maintainers can choose the public API shape; access to the existing resource representation would suffice. Callers remain responsible for ownership checks and desired-state comparison.

Acceptance Criteria

• Image-based creation accepts policy without requiring a workload template or subsequent policy update.
• Workspace create/get exposes returned identity, resource version, labels, deletion metadata, and status.
• Sandbox create/get exposes returned identity, metadata, stored specification, and status, including startup conditions.
• These details are available from the create response itself, without a second GET to recover omitted fields.
• Absent metadata, specification, or status remains distinguishable from a present default-valued object.
• Tests and a usage example cover this workflow; existing default behavior is preserved and any source-compatibility implications are documented.

Alternatives Considered

• Keep using raw gRPC: retains the downstream integration code.
• Create a template solely to supply policy: adds another resource to manage.
• Update policy after creation: cannot establish the intended policy in the initial request.

Agent Investigation

Source review confirmed both gaps in SDK types at main revision 0b351c4. No live gateway test was performed for this proposal.

Related: #2680 (workload/template API), #3398 (completed sandbox-scoped provider/policy/settings SDK methods), and #2565 (API/SDK stabilization). This request is limited to the create/read workflow above.

Checklist

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