This follow-up addresses lifecycle gaps found during review of PR #892.
clearSession() did not create a stop tombstone when no session-state record existed yet, so a first queued invocation could activate after cleanup.user_stopped.blocked_url or user_stopped.cursor_position formatting existed without a production backend result.clearSession(A) could discard retained observations and keyboard ownership for unrelated session B.The Runtime treated observation and mutation leases as the only operations that needed lifecycle fencing. Cleanup also mutated only an already-created state record, while terminal transitions shared the same unrestricted transition helper as recoverable states.
The executor queue was scoped to the caller rather than the resource being validated. Ambiguity signatures also mixed stable identity with snapshot-local IDs, and the cursor result test used only a fake backend.
The backend also inferred generation loss from the release reason. The no-in-flight clearSession() path emits session_cleared without stopping the child, so the reason alone cannot establish that shared executor state changed.
clearSession().blocked_url and user_stopped absorb later lifecycle events.get_cursor_position through the pinned cua-driver and return the resolved point without moving the pointer.generationReleased as an explicit service release fact. Session-only releases invalidate only their listed sessions; actual child exits sweep all retained session observations and keyboard targets.A new turn still creates a fresh Computer Use session state, preserving the existing explicit recovery boundary.
npm --workspace @maka/runtime run typechecknpm --workspace @maka/runtime testnpm --workspace @maka/computer-use testgit diff --check