Add an atomic run-tree purge capability for retention workflows

Problem

A downstream framework needs to satisfy durable session deletion. Cancelling a Workflow run is not sufficient: the root and descendant runs can remain streamable, resumable, or addressable, and retained execution data can outlive the application record that identified it.

The public repository exposes World storage abstractions and local/Postgres implementations, while the Vercel production World delegates to the private workflow-server service. There is currently no public capability contract for atomically purging a root run tree.

Proposed semantics

Add an optional World run-tree purge capability that:

• fences new writes for the root and descendants;
• cancels active work before deletion;
• removes the root and descendant run data, including events, steps, streams, hooks, tokens, snapshots, and owned blob references;
• returns success for an already absent tree;
• returns a retryable conflict when active work cannot yet be atomically cancelled and purged;
• returns success only when the tree is no longer streamable, resumable, or addressable.

Local and Postgres implementations can live in this repository. The Vercel adapter needs a matching workflow-server operation owned by the managed service; the client must not advertise support until that backend exists.

Concrete use case

Rabbit Studio uses Eve sessions for minors projects. When a Rabbit thread, project, kid, or account is deleted, Rabbit API durably queues provider cleanup. It needs a provider operation that proves root-plus-descendant removal before it clears the external session identifier.

Verification requested

Coverage should include absent, active/conflict, concurrent purge, partial retry, root-plus-descendant removal, unrelated-run preservation, and post-delete stream/resume rejection for every supported World backend.

Start with the public World storage abstractions and the local/Postgres implementations, then inspect the Vercel adapter boundary to confirm where support can be advertised. Verify absent, active/conflict, concurrent and partial-retry behavior, root-plus-descendant deletion, unrelated-run preservation, and post-delete stream/resume rejection for each supported backend.