Check allowed service ports before creating a sandbox or opening a forward #5110

User Story

I use OpenShell service forwarding across backends with different network isolation. I need to know which target ports a sandbox may expose, and whether they use a private runtime network or the shared host network, before a forward or service endpoint is created.

Problem Statement

The compute admission response cannot describe a fixed set of approved forwarding targets and their network scope. The gateway and clients therefore cannot check these limits consistently before provisioning or opening a listener.

They also need to distinguish private loopback, shared host loopback that the caller explicitly accepted, and backends that do not support incoming service connections.

Impact / Why This Matters

A forward can appear ready and then fail on its first connection. Users can also mistake a service on the shared host network for one inside an isolated runtime.

OpenShell should reject unapproved targets early, show their network scope clearly and keep enforcing the approved targets in live gateway routes.

Proposed Design

Admit target ports before provisioning and retain the admitted envelope with the sandbox. CLI and SDK forwarding should reject an unadmitted target before binding a listener. Gateway TCP and HTTP routing remain authoritative, including when reusing a connection. Report shared host scope explicitly. SSH transport remains available independently of service-port admission.

Example workflow for review: For a sandbox admitting target port 8080 on shared host loopback, report that scope explicitly. A request for port 9090 must fail before provisioning or opening a local forward; the admitted 8080 route still needs server-side ownership checks.

Acceptance Criteria

• Unadmitted create-time forward and service ports fail before provisioning.
• Live TCP and HTTP routes enforce the retained envelope; clients fail before binding.
• Missing evidence under the negotiated contract denies ingress, while legacy absence remains distinguishable.
• Inspection identifies isolated loopback, explicitly opted-in shared host loopback or unsupported ingress. SSH transport remains independently usable.
• Direct gateway requests and reused HTTP connections cannot bypass the retained admission envelope.

Alternatives Considered

Client-only validation misses raw RPC callers and HTTP connection reuse. An isolation backend still owns actual socket enforcement; middleware, providers and gateway interceptors cannot replace the compute driver's resolved ingress admission.

Coordinate the declared-service portion with service exposure (#4310 / RFC 0017). The RFC explicitly leaves CLI forwarding outside its scope, so retain the missing control-plane admission contract rather than claiming the RFC implements it.

Agent Investigation

No response

Checklist

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