feat(supervisor): expose sandbox name to supervisor middleware #2754

Problem Statement

Operator-run supervisor middleware receives the originating sandbox ID in RequestContext, but not the sandbox name. This makes middleware audit and approval interfaces harder for operators to interpret because they must display an opaque UUID or maintain a separate ID-to-name mapping.

The sandbox supervisor already knows both values. Its process-wide SandboxContext contains sandbox_id and sandbox_name, but the middleware request path currently copies only the ID into HttpRequestInput and the protobuf RequestContext.

Related umbrella issue: #1733.

Proposed Design

Extend supervisor middleware request context with the originating sandbox name:

1. Add string sandbox_name = 4 to RequestContext in proto/supervisor_middleware.proto. Keep the existing field numbers unchanged for wire compatibility.
2. Add sandbox_name to openshell_supervisor_middleware::HttpRequestInput.
3. Populate both sandbox_id and sandbox_name from the existing process-wide openshell_ocsf::SandboxContext when the supervisor constructs middleware input.
4. Copy the name into the operator-run gRPC request context. Built-in middleware may ignore it unless needed.
5. Update middleware protocol documentation and tests to cover propagation of both identifiers.

The field should contain the canonical sandbox name known to the running supervisor. An unavailable name should remain an empty string, matching protobuf string defaults and preserving compatibility with older supervisors. Older middleware services will ignore the unknown field, while newer services remain compatible with older supervisors that omit it.

The existing middleware request-context size limit remains applicable.

Alternatives Considered

• Resolve the UUID through the gateway from each middleware service. This adds control-plane authentication, availability, and latency dependencies to a data-plane request hook.
• Configure a static sandbox label in each middleware policy. This duplicates identity data, can become stale after renames or policy reuse, and does not work cleanly for one service handling multiple sandboxes.
• Display only the sandbox ID. IDs are stable but are difficult for humans to recognize in approval and audit interfaces.

Passing the name beside the existing ID uses data the supervisor already owns and keeps middleware services self-contained.

Agent Investigation

• Searched existing issues for RequestContext, sandbox name, and supervisor middleware; no focused duplicate was found.
• proto/supervisor_middleware.proto currently defines request_id = 1, sandbox_id = 2, and originating_process = 3 in RequestContext.
• crates/openshell-supervisor-middleware/src/lib.rs carries only request_id and sandbox_id in HttpRequestInput.
• crates/openshell-supervisor-network/src/l7/middleware.rs currently reads only openshell_ocsf::ctx::ctx().sandbox_id when constructing middleware input.
• crates/openshell-sandbox/src/lib.rs already initializes SandboxContext with both the sandbox ID and sandbox name, so no new lookup is required.

Checklist

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