feat(cli): add --output json/yaml to sandbox get, status, and sandbox create

[rhuss]

Summary

Add --output json/yaml to sandbox get, status, and sandbox create so automation and MCP tool wrappers can consume structured data instead of parsing ANSI-colored human output.

Related Issue

Closes #1964

Changes

• sandbox get --output json/yaml: New sandbox_detail_to_json converter enriches the existing sandbox_to_json with policy source, revision, and active policy content from GetSandboxConfigResponse. Uses sandbox_policy_to_json_value for direct proto-to-JSON conversion.
• status --output json/yaml: New status_to_json converter emits gateway, server, status, and conditional fields (auth, version, error, http_status). Refactored gateway_status to build data before output routing.
• sandbox create --output json/yaml: Emits sandbox metadata after Ready phase. Human chrome (header, spinner) suppressed from stdout; progress message on stderr. Uploads and port forwarding still execute before output. Clap rejects --output combined with --editor or trailing commands.
• No-gateway path: status --output json with no configured gateway emits {"status": "not_configured"} instead of human text.
• All three commands reuse the existing OutputFormat enum and print_output_single helper.
• Default output (no --output flag) is byte-identical to current behavior (verified by diffing raw ANSI output).
• Docs updated for sandbox get, sandbox create, and status in manage-sandboxes.mdx and manage-gateways.mdx.

Testing

• cargo clippy clean, cargo fmt clean
• 188 unit tests pass (cargo test --lib)
• 5 new unit tests for sandbox_detail_to_json and status_to_json converters
• Integration test call sites updated for new function signatures
• Smoke-tested against live local gateway: sandbox get --output json, status --output json/yaml, default output byte-identical regression check
• Deep review (5 agents + CodeRabbit + Copilot): all Critical/Important findings fixed

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

All contributors have signed the DCO ✍️ ✅
_{Posted by the DCO Assistant Lite bot.}

[rhuss]

I have read the DCO document and I hereby sign the DCO.

[rhuss]

recheck

[johntmyers]

This isn't byte-for-byte identical I don't think. If http_health_check() returns None then we used to show Error: ... but now it should hit this arm and will show gRPC error:

[rhuss]

Good catch. When http_health_check() returns None (no HTTP reachability at all), the original code used "Error:" as the label, not "gRPC error:". My refactoring incorrectly used "gRPC error:" for all cases in the "error" arm.

Fixed: the "error" arm now checks whether HTTP status is present. If yes, it shows both "HTTP:" and "gRPC error:" (matching the original dual-reachability case). If no HTTP status, it shows "Error:" (matching the original no-reachability case).

Applied in 9aa0ec4.

[rhuss]

(I'm still on it, not sure if this is the best solution)

[johntmyers]

Is there a reason this does not propagate the conversion error? Other parts do, do we really want to return a null policy if conversion fails?

[rhuss]

You're right. Changed sandbox_detail_to_json to return Result<serde_json::Value> and propagate the conversion error via wrap_err. This matches how sandbox_settings_get (line 7213) handles sandbox_policy_to_json_value errors.

Applied in 9aa0ec4.

[rhuss]

@johntmyers thanks for the review! As I'm on my way to dive into the codebase I will try to understand the codebase a bit better (not a Rust coder yet). But I think your comment ironically also hint to a problmen that this PR tries to partially solve: We need to be careful currently around the wording of log/error messages as they are parsed and used for result evaluation (i know at least one tool that wraps that parses the output of sandbox instead of using the SDK directly).

Therefor having the option for a structured output make much sense for these use cases. I wonder though, whether one should keep stderr free for informal messages or whether not (if -o json) is given also the error messages should be structured (I tend to the later). What's your take on this ?

[rhuss]

I'll create a follow-up issue for emitting structured JSON errors when --output json/yaml is active, so automation consumers get parseable error responses instead of miette-formatted text. That's a broader change touching the error handling in main() and should cover all commands, not just the three in this PR.