container lifecycle: resume sandboxes across exo processes

[akrentsel]

What this changes

Container lifecycle becomes resume-aware. Before this PR, every exo invocation created a fresh sandbox; after it, an agent continuing a conversation picks up the same sandbox it was using.

Lifecycle on every run_in_sandbox

when the conversation has a recorded sandbox_id:

    (a) container is running
            └─► attach and use it

    (b) container exists but is stopped
            └─► `docker start` it, then use it

    (c) container is gone (rm'd, TTL-expired, server-side auto-cleanup)
            │
            ├─ (i)  conversation log has a snapshot for this sandbox
            │       └─► restore the latest snapshot, use it
            │
            └─ (ii) no snapshot ever taken
                    └─► create a fresh container from base image

otherwise (no recorded sandbox_id):
    └─► create a fresh container from base image

Tiers (a) and (b) are unified inside backend.try_resume. Tier (c)(i) goes through the existing start_sandbox / acquire_from_snapshot path that #20 introduced. Tier (c)(ii) is the current create_sandbox path.

What changed

Layer	Change
trait	new ManagedSandboxBackend::try_resume(req) -> Option<Handle>: "find the sandbox for this SandboxKey, start it if stopped, attach if running, return None otherwise."
Docker / AppleContainer	implements try_resume via docker ps -a --filter label=exo.sandbox.key=… (and container list --format json for Apple), matches by spec-hash, reaps drifted entries, enforces cross-process idle TTL via docker inspect .State.FinishedAt.
LocalProcess	try_resume always Ok(None) — no persistent identity to resume.
Drop	Drop for CliContainerSandboxBackend now does docker stop -t 0 instead of docker rm -f. Containers survive process exit, labelled and ready for the next exo invocation to find.
run_in_sandbox	on in-memory cache miss, calls backend.try_resume and binds the handle. The old error "sandbox is not active in this process" only fires now when the cross-process lookup also misses.
ensure_shell_sandbox	runs the 3-tier chain above. Tier 2 (snapshot restore) walks SandboxSnapshotted events for the recorded sandbox_id.
tests	one new integration test: two cross-process chat send invocations against one conversation produce exactly one docker container.

User-visible behavior change

• Before: exit exo → all warm containers docker rm -f'd. docker ps -a was clean after exit.
• After: exit exo → warm containers stopped (Exited state on host). docker ps -a shows them. They get cleaned up the next time exo runs a sandbox that's been idle past the TTL (5 min default, the existing idle_seconds=300 from ensure_shell_sandbox).

If a user previously relied on "exit exo, zero residue on the host," this is a behavior change. The trade-off is what enables resume; manual docker rm still works for anyone who wants the old behavior on demand.

Stack

main
  └── #20  sandbox-snapshots-filesystem    Docker snapshot + rewind
        └── #21  this PR                   Cross-process resume + 3-tier fallback
              └── (follow-up)              Daytona backend, inherits the resume contract

Test plan

• cargo test --workspace — 51 unit tests pass
• EXO_TEST_SANDBOX_BACKEND=docker cargo test -- --ignored — both integration tests pass (existing one with updated container-state assertion, and the new cross-process resume test)
• Manual end-to-end: chat send 'echo foo > /tmp/x.txt' then in a separate exo invocation chat send 'cat /tmp/x.txt' — the file persists, same container is resumed.

🤖 Generated with Claude Code

[akrentsel]

Added tests, shown passing here: https://github.com/ankrgyl/exo/actions/runs/26390452231/job/77678665189

[akrentsel]

Ready for review here: @ankrgyl