[Feature]: Make durable state and memory backends pluggable

[Fangjj0621]

Is there an existing issue for the same feature?

• I have checked the existing issues.

Is your feature request related to a problem?

As a self-hosting developer, Astra currently appears tightly coupled to MatrixOne for durable runtime state and Memoria for memory. Both may be good defaults, but requiring them makes Astra difficult to adopt inside an existing platform that already standardizes on PostgreSQL/MySQL and another memory or retrieval service.

The runtime describes itself as model-provider independent and embeddable. Storage and memory need similarly explicit provider contracts; otherwise adopting the runtime also means adopting the full MatrixOrigin data stack.

Describe the feature you'd like

Define stable internal provider interfaces and conformance suites for:

1. durable control/transcript/audit/trace storage;
2. memory retrieval and persistence;
3. optional artifact/blob storage.

Keep MatrixOne and Memoria as first-class reference implementations, but make backend capability and guarantee differences explicit. A backend should declare support for transactions, leases/fencing, ordering, isolation, retention, vector retrieval, and deletion propagation rather than relying on implicit SQL behavior.

At minimum, provide one lightweight alternative implementation for development and a documented path for a PostgreSQL adapter.

Acceptance criteria

• Runtime services depend on documented storage/memory traits rather than MatrixOne/Memoria-specific assumptions at their public boundary.
• A backend capability manifest describes required and optional guarantees.
• Conformance tests cover lifecycle transitions, owner fencing, idempotency, event ordering, cross-user isolation, and deletion propagation.
• MatrixOne and Memoria remain supported reference backends.
• Documentation explains which Astra features degrade or are unavailable with a less capable backend.
• A minimal local backend can run the basic API and chat contract tests.

Implementation / design notes

This should not become a lowest-common-denominator abstraction. The provider contract should allow MatrixOne-specific optimizations while keeping correctness requirements portable and testable.