feat(server): replace shell string exec with structured protocol (SEC-002 follow-up) #556

Problem Statement

The exec_sandbox gRPC handler converts structured ExecSandboxRequest fields (command array, environment map, workdir) into a single shell string via build_remote_exec_command, which is then passed through SSH to bash -lc on the sandbox side. This structured-to-unstructured conversion is architecturally weaker than direct structured execution, even with the defensive hardening applied in PR #548 (SEC-002).

The current hardening (null byte / newline rejection, size limits, shell_escape) mitigates practical exploitation, but the fundamental pattern of flattening structured data into a shell string and re-parsing it remains a latent risk surface.

Proposed Design

Replace the shell string protocol with a structured command protocol:

1. Server side (grpc.rs): Instead of calling build_remote_exec_command to flatten the request into a shell string, serialize the ExecSandboxRequest fields (command array, environment map, workdir) as JSON or protobuf.
2. Transport: Send the structured payload over the SSH channel (e.g., as a JSON blob followed by a newline, or via a dedicated protobuf message).
3. Sandbox side (ssh.rs): Parse the structured payload and execute the command using execvp (or Command::new in Rust) directly — no shell interpretation at all. Environment variables are set via the process builder, and workdir is applied via std::env::set_current_dir or Command::current_dir.

This eliminates both shell interpretation layers entirely.

Key considerations

• Backward compatibility: the sandbox SSH server needs to support both the old shell string protocol and the new structured protocol during a transition period (version negotiation via the NSSH1 preface, or a separate channel type).
• The shell_escape and build_remote_exec_command hardening from PR fix: security hardening batch 1 (SEC-002 through SEC-010) #548 should remain as a fallback path until the transition is complete.

Alternatives Considered

• Keep shell string with stronger escaping: Already implemented in PR fix: security hardening batch 1 (SEC-002 through SEC-010) #548. Reduces risk but doesn't eliminate the architectural weakness.
• Use SSH environment variables: SSH supports env requests, but many SSH server configs restrict which env vars can be set. Not reliable.

Agent Investigation

Codebase analysis from the SEC-002 security review (PR #548):

• build_remote_exec_command at crates/openshell-server/src/grpc.rs:3424
• shell_escape at crates/openshell-server/src/grpc.rs:3410
• run_exec_with_russh at crates/openshell-server/src/grpc.rs:3733 sends command via channel.exec(true, command.as_bytes())
• Sandbox side exec handling in crates/openshell-sandbox/src/ssh.rs