Clarify or support compound commands in session exec

[ElysiaFollower]

Context

Socratic Tutor uses Remote Runner as the evidence collection layer for lab sessions. A normal shell user, and often an LLM tutor, may naturally try compact probes such as:

id && whoami
pwd && ls -la

In the deployed Socratic integration, id && whoami was rejected before execution with:

Command is not allowed by Remote Runner command policy.

That is acceptable from a policy perspective, but the current contract is ambiguous for tool callers: it is hard to distinguish "the command is dangerous" from "this is a compound command whose individual segments may be acceptable".

Desired behavior

Remote Runner should make compound-command behavior explicit. A good outcome would be one of these:

1. Support simple compound commands in session exec when each segment is individually valid for the caller policy, preserving stdout/stderr/exit code in the normal command result; or
2. Return a structured, machine-readable rejection reason such as compound_command_not_supported or command_policy_rejected, so clients can split and retry with single commands.

Why this matters

For Socratic Tutor, we prefer teaching-oriented single-command observations because they are easier for students to read and reason about. Still, the tutor needs robust recovery when a compact shell expression is rejected. A structured Remote Runner contract would let the tutor distinguish:

• retry as id, then whoami; versus
• stop because the command is genuinely disallowed.

Reproduction shape

Using a persistent session:

remote-runner session exec --session <session-id> --cmd 'id && whoami' --mode wait --json

Expected contract should clearly state whether compound commands are supported and, if not, why they were rejected.