Supported target-scoped context maintenance and lifecycle reads for agents

[grasdal]

An agent can read a thread through the public orchestration projection, but cannot obtain a documented maintenance operation with same-native-thread guarantees or a complete lifecycle observation suitable for conservative archival. The native adapters already support context compaction; the missing part is an explicit public service contract and the admission/readback needed for unattended recovery.

I am requesting agreement on direction and scope before implementing these public routes, as CONTRIBUTING.md requires. This proposal is separate from the small Codex goal-length validation bug fix.

Proposed smallest scope:

• Extend the existing thread management/lifecycle services, with thin typed HTTP/RPC/MCP surfaces. A read returns only the requested thread's identity, executing run/attempt/latest native turn, queue/runtime requests, target-owned background work and session residency. Each fact carries observed state or explicit unknown plus snapshot provenance. Omitted/defaulted arrays cannot certify absence. No global thread or process inventory, message content, credentials or hidden provider reasoning is returned.
• A context-maintenance request identifies the target and expected strong native actor, provider instance, exact model/options and permission/interaction modes. It is admitted against current serialized state, refuses conflicting pending work or uncertain residency, and routes to the existing native compaction implementation. Preserve durable messages, history, context handoffs and native ownership; do not change model/account/provider or consume deferred handoffs as an ordinary prompt. Return a durable operation identity and exact target/terminal outcome for readback.
• Keep read observations separate from mutable admission. A snapshot sequence is not a lease. Admission must revalidate identity/settings and relevant work inside the command transaction; any asynchronous effect repeats necessary checks and refuses drift. If background/process completeness cannot be established by existing session ownership, the endpoint reports unknown and archival remains refused.

Qualification would cover same-owner compaction, unsupported providers, wrong-target/mode/model/native identity, incomplete historical facts, queued or active competing work, background tasks, process/session loss, handoff preservation, drift between admission and effect, uncertain delivery and exact terminal readback. Tests use controlled fixtures only, with no operation on real user threads.

The implementation base currently inspected is upstream main 3857132. Existing services are ThreadManagementService, ThreadLifecycleService, ProviderSessionManager and RunExecutionService; provider references and run/attempt/turn joins are in packages/contracts/src/orchestrationV2.ts. The proposal deliberately leaves final wire names and whether process completeness should be supported or explicitly unknown to maintainers.

Is this direction acceptable, and should it be one maintenance capability with a target-only observation method or two separate proposals? No implementation or deployment of these routes is claimed.