V2: port transform and interruption durability across both model paths

[opencode-agent]

Scope

Port the existing transform and interruption durability behavior to V2 in packages/core. This must cover both model execution paths:

• the @opencode-ai/llm path;
• the AI SDK path.

Neither path should have weaker persistence or recovery semantics.

Requirements

• Persist transform results needed for deterministic replay/recovery before dependent continuation or side effects.
• Represent interruption durably and settle any in-flight assistant/tool state without leaving orphaned or permanently pending parts.
• After replay or restart, project the same terminal/interrupted state rather than a successful-looking incomplete message.
• Keep the durability contract aligned across both paths, ideally behind shared core behavior rather than two drifting implementations.
• Add a parity test matrix covering normal completion, user interruption, and interruption followed by replay/restart for each path.

Related lifecycle/error-event design: #35016
Related typed LLM error work: #34995

Source: https://discord.com/channels/1391832426048651334/1447692703549755466/1523404602102517941

[kitlangton]

Observed a concrete V2 restart incident in session ses_0c5c99a08ffe3fP9CyeC5E2z8F.

The computer restarted while shell work was in flight. On reopening the session, the TUI rendered the persisted shell parts as active, including spinners, “Writing command...”, and the ctrl+b background hint, even though the previous process no longer existed. The durable event log still ended with an unfinished step and non-terminal tool state.

The stale state was only settled after sending another message: the new prompt produced session.prompt.admitted.1 / session.execution.started.1, followed by session.tool.failed.1 for both orphaned calls. The TUI then showed them as interrupted. This confirms restart/replay does not immediately project a terminal interrupted state; reconciliation is deferred until the next prompt.

[thdxr]

Closing this tracker after the recent V2 server lifecycle, restart continuity, reconnect hydration, and synchronization work. This area has changed substantially, and we want to track any remaining or newly reproducible behavior as a fresh, focused issue against the current implementation.