[Feature]: Expose conversation runtime lifecycle and recovery capabilities

Is there an existing feature request for this?

• I have searched existing issues and feature requests, and this is not a duplicate.

Problem or Use Case

PR #3403 introduces an outer Agent Server that can own per-conversation runtimes, but the public conversation contract does not distinguish agent execution state from runtime availability. Today a missing container, an execution failure, and lost runtime ownership can collapse into similar errors, leaving clients unable to decide whether recovery is possible.

This contract is necessary before archive or Canvas work because runtime missing != conversation archived and execution failed != runtime missing.

Desired Behavior

Expose canonical lifecycle metadata for every conversation, including a typed execution status, runtime status, can_resume, and structured runtime error details. Add outer-server operations that query runtime availability, reprovision a missing owned runtime around retained state, and explicitly resume after reprovisioning. Ownership loss should be represented as lifecycle data rather than converted into an agent execution error.

This work should build on the conversation-scoped runtime API and #3403 without expanding #3403 beyond its Docker runtime foundation.

Acceptance Criteria

• Conversation responses expose additive, typed execution_status, runtime_status, can_resume, and optional runtime_error fields.
• Runtime status distinguishes at least available, starting, missing, and ownership-lost states.
• The outer Agent Server can query availability without provisioning a runtime.
• A missing runtime can be reprovisioned only when retained state and ownership make recovery safe.
• Resuming execution is explicit and separate from reprovisioning.
• Local mode remains backward compatible and Docker-mode tests cover container loss, ownership loss, reprovision, and resume.
• OpenAPI and clients/typescript are regenerated or updated in the same PR.
• Public API documentation explains lifecycle semantics.

Alternatives Considered

Inferring lifecycle from HTTP failures or a legacy Cloud sandbox_status leaves clients coupled to deployment details and cannot distinguish archive, runtime loss, or execution failure.

Priority / Severity

High - Significant impact on productivity

Estimated Scope

Large - Significant feature requiring architecture changes

Feature Area

• Agent Server
• Integrations (GitHub, APIs, etc.)

Technical Implementation Ideas (Optional)

Use explicit enums/models in the Agent Server contract and keep runtime-specific inspection behind the existing runtime route/registry abstraction. Prefer additive fields to preserve REST compatibility.

Additional Context

Foundation: #3403. This is the first follow-up in the lifecycle/archive stack.

This issue was created by an AI agent (OpenHands) on behalf of the user.

Start with the conversation-scoped runtime API and the Agent Server runtime route/registry abstraction, using #3403 as the foundation. Review the OpenAPI contract and clients/typescript generation path before defining the lifecycle surface. Done means the listed lifecycle fields and outer-server operations are covered, Docker-mode loss and recovery cases are tested, local mode remains compatible, and public API documentation explains the semantics.