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/bins/teamclaw-server/Cargo.toml

@@ -17,6 +17,7 @@ tc-db = { path = "../../tc-db" }
 tc-files = { path = "../../tc-files" }
 tc-llm = { path = "../../tc-llm" }
 tc-runtime = { path = "../../tc-runtime" }
+tc-sandbox = { path = "../../tc-sandbox" }
 tc-scheduler = { path = "../../tc-scheduler" }
 tc-domain = { path = "../../tc-domain" }
 time = { workspace = true }