Reopening a failed durable session returns opaque internal_error

Problem

A durable session can enter state.status === "failed" after its ACP adapter exits during a prompt—for example, after exceeding limits.jsRuntime.cpuTimeLimitMs. getSession({ sessionId }) correctly preserves a useful serialized failure such as prompt_interrupted.

Calling openSession(...) again with the same durable sessionId does not restore or reset the adapter. Through the RivetKit actor API it instead returns only:

group=rivetkit code=internal_error message="An internal error occurred"

The stored failure explaining why the session cannot be reopened is lost at the action boundary. A fresh session on the same actor still opens successfully.

Expected behavior

One of the following would make this lifecycle recoverable:

1. openSession restores or resets a session whose durable state is failed; or
2. it returns a typed terminal error such as session_failed, including the stored serialized failure and documenting that callers must call deleteSession before recreating it.

It should not collapse this state into a generic internal_error.

Reproduction outline

1. Create a durable Pi session with a stable sessionId.
2. Cause the adapter to exit during a prompt, such as by using a small JavaScript CPU-time budget.
3. Confirm getSession({ sessionId }) reports state.status === "failed".
4. Call openSession again with the same sessionId and original options.
5. Observe the opaque RivetKit internal_error.
6. Open a new session ID and observe that it succeeds.

Observed with @rivet-dev/agentos@0.0.0-fix-main-wasm-ownership.8ca391b on the RivetKit actor path.

Start with the durable-session openSession/getSession lifecycle and the RivetKit actor API described in the reproduction; reproduce the failed-session reopen path using a constrained JavaScript runtime budget. Done means reopening restores or resets the failed adapter, or returns a typed session_failed error containing the stored serialized failure instead of internal_error.