Show the workload operating system, architecture, and execution restrictions #5201

User Story

I use OpenShell on an Apple silicon Mac to run native tools. Before starting an agent, I need to know which operating system and architecture will run its commands, and which execution restrictions the runtime always applies.

Problem Statement

Gateway inspection does not provide a common view of the workload's operating system, architecture and fixed execution restrictions. The gateway host alone does not answer this: a gateway on macOS can run a Linux VM or native macOS workloads through an extension.

For example, a tested native macOS sandbox runs id but refuses /bin/ps before it starts. On that Mac, /bin/ps is setuid root and the operating system reports forbidden-exec-sugid; the shell only shows Operation not permitted.

Impact / Why This Matters

Users and agents discover compatibility limits through failed commands or runtime-specific documentation. They may choose a Linux-only command for a macOS workload, or retry policy changes and installation repairs that cannot remove a fixed runtime restriction.

A shared inspection interface would help people and automation understand the selected runtime before starting work. It should report what the runtime declares without promising to predict every command failure.

Proposed Design

Extend OpenShell's existing inspection workflow with runtime-declared workload compatibility information. Start with the workload operating system, architecture, and a short explanation of fixed execution restrictions the runtime can report. Keep the information available through the gateway, with readable CLI output and structured output for automation.

Illustrative output; field names and formatting are proposals:

$ openshell --gateway native gateway info
Workload platform: macOS / arm64
Execution restrictions:
  Setuid executables cannot run in this runtime.

$ openshell --gateway linux-vm gateway info
Workload platform: Linux / arm64

Acceptance Criteria

• Inspection identifies the selected driver's workload platform, separately from the gateway host. A Linux VM on macOS reports Linux for its workload.
• A runtime can report fixed execution restrictions with a short explanation users can act on, including the privileged-executable example above when applicable.
• Human-readable and structured gateway output agree. Missing information remains unreported rather than being inferred from the CLI host or treated as unrestricted execution.
• Existing sandbox operations and their exit status remain intact. Inspection neither weakens isolation nor selects another runtime automatically.
• Documentation shows how humans and agents inspect compatibility and distinguishes declared restrictions, installation health, and request-specific policy decisions. It does not promise that inspection predicts every command failure.

Alternatives Considered

Runtime documentation alone. It remains useful, but a caller connected to a gateway cannot discover which restrictions apply to that configured runtime through the common OpenShell interface.

Only improve startup errors. #3519 should handle entrypoint failures. It cannot explain a restriction before creation or cover every command later entered into an interactive shell.

Reuse compute-driver and isolation-backend discovery. This is the preferred foundation. The proposal asks OpenShell to expose information from the extension that owns it, without an in-tree macOS driver or a CLI table of platform-specific command rules.

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