Suspend idle Docker conversation runtimes after terminal states

Problem or Use Case

A Docker-backed Agent Server keeps one container alive for every conversation that has been opened since the outer server started. On the shared OSS Agent Canvas host, 24 idle conversation containers remained running, used about 4.5 GB in writable layers, and contributed to severe I/O and memory pressure. The host reached 97–98% disk usage and Automation requests began failing. Restarting the outer server cleans these containers, but routine operation should not require a restart.

Desired Behavior

After a Docker-backed conversation reaches a terminal agent state and has no active request or socket, release its container while preserving the bind-mounted conversation, workspace, and provisioning data. A later interaction with the conversation should recreate the runtime through the existing DockerConversationRegistry.get_or_create() path and resume normally.

Acceptance Criteria

• A Docker conversation in a terminal execution state releases its container once no request or socket is actively using that runtime.
• Running conversations and conversations with an active request or socket are not suspended.
• Reopening or sending a message to a suspended conversation recreates its container and preserves its conversation ID, event history, workspace files, profile, and secrets boundary.
• Suspending a runtime does not delete its persisted conversation, workspace, or provisioning data; deleting a conversation continues to remove the appropriate persisted state.
• Concurrent release and resume requests cannot leave duplicate containers or make the conversation permanently unavailable.
• Focused tests cover release, safe non-release while active, and successful resume with persisted state.
• The Agent Server documentation explains the lifecycle and distinguishes runtime suspension from conversation deletion.

Alternatives Considered

A host-level cron job can stop old containers, but it cannot reliably know whether a runtime has an active request and bypasses the registry's locking and lifecycle rules. Increasing the VM disk only delays recurrence.

Priority / Severity

High — the accumulation caused a live shared Canvas and its Automation backend to become unavailable.

Estimated Scope

Medium — the registry already supports stopping and recreating containers, but release must be coordinated with active proxy traffic.

Feature Area

• Agent Server
• Workspace management
• Performance / Optimization

Start by tracing DockerConversationRegistry.get_or_create() and the existing container stop/recreate lifecycle, then inspect how active requests and sockets are tracked. Add focused coverage for safe release and resume with persisted conversation and workspace state, including concurrent release and resume. Update the Agent Server documentation to distinguish runtime suspension from conversation deletion.