006 MVP Docker Sandbox Orchestration

Context

The service needs a first MVP for sandbox orchestration behind /api/v1/create.
The first version must stay small, avoid auth, and preserve clean architecture boundaries.

Decision

Use Docker as the outer runtime adapter for sandbox start and stop operations.
Keep sandbox entities and errors in domain/ and orchestration ports in usecase/.
Use an in-memory session repository for the MVP instead of a central database.
Keep one active sandbox per chat_id and reuse it until TTL expiry.
Set default sandbox TTL to 300 seconds.
Mount chat storage as rw, dependencies as ro, and lambda-tools as ro.
Run expired sandbox cleanup as an in-process background loop in the HTTP app lifecycle.

Consequences

Inner layers stay free from Docker and FastAPI details.
The MVP is single-instance oriented and not yet suitable for multi-node coordination.
Repository and runtime can be replaced later without changing usecase contracts.