P6: shell.exec — agents execute code in their real hardened sandbox

- SandboxManager (tc-runtime): one container per agent, provisioned
  lazily on first use, reused for the manager's lifetime, replaced
  transparently if dead, destroyed on shutdown
- shell.exec tool: sh -lc inside the agent's sandbox; stdout/stderr/
  exit_code return to the model as the step output. No external effects
  declared — the sandbox boundary (uid 10001, no caps, seccomp
  allowlist, read-only rootfs, zero egress) is the §15 control here,
  not an approval gate
- RuntimeConfig.sandboxes (+ with_sandboxes builder); [sandbox] config
  {image, enabled}; the server connects the Docker driver at boot and
  tolerates an absent engine (shell.exec reports it per-call)
- Tests with the REAL DockerDriver: a scripted run executes two
  commands — output proves uid 10001 from inside, and /home/agent state
  written by the first call is read by the second (same sandbox); a
  deployment without a sandbox runtime records honest error steps and
  the run still completes

151 Rust tests + 27 Playwright journeys.

Co-Authored-By: Claude Fable 5 <[email protected]>

crates/tc-runtime/src/lib.rs

@@ -4,9 +4,11 @@
 
 mod events;
 mod runtime;
+mod sandboxes;
 pub mod scheduling;
 mod tools;
 
 pub use events::{RunEventBody, RunEventEnvelope};
 pub use runtime::{Runtime, RuntimeConfig, RuntimeError, StartedRun};
+pub use sandboxes::SandboxManager;
 pub use tools::{ClockNow, EmailSend, Tool, ToolContext, ToolRegistry};