[Release]: Publish a pre-1.0 compatibility, upgrade, and support policy

[Fangjj0621]

Is there an existing issue about this?

• I have checked the existing issues.

Describe the issue

As an external developer, I cannot determine which Astra artifact should be used for a reproducible evaluation or deployment.

The repository identifies the workspace version as 0.1.0 and warns that public interfaces may change before 1.0, but the canonical repository currently has no GitHub Release entry. There are older tags, active binary/image release workflows, and rapidly changing API, SDK, database, Runner, and event contracts, but no single compatibility and support policy tying them together.

Building from main is acceptable for contributors; it is not a safe consumption model for SDK users or self-hosted operators.

Suggested improvement

Publish a canonical pre-1.0 release process and compatibility matrix covering:

• CLI ↔ Server compatibility;
• Edge/User Runner ↔ Server compatibility;
• TypeScript SDK ↔ HTTP API compatibility;
• database schema/migration compatibility;
• MatrixOne and Memoria supported versions;
• configuration-file schema versions;
• trace/event and checkpoint wire compatibility;
• upgrade, downgrade, and rollback expectations;
• security support window and vulnerability reporting process.

Each release should provide immutable CLI binaries and container digests, migration notes, known limitations, and a link to the capability maturity/conformance result for that commit.

Acceptance criteria

• The canonical repository publishes a GitHub pre-release with immutable artifacts or verified links to them.
• A documented versioning policy explains what may break before 1.0.
• A compatibility table covers CLI, Server, Edge, SDK, schema, MatrixOne, and Memoria versions.
• Upgrade and rollback procedures are tested and documented.
• Supported releases have a vulnerability reporting and patch policy.
• README quickstarts use a release tag or digest instead of implicitly depending on moving main.

Additional information

The repository already contains release workflows and .github/release.yml; this issue is about the external consumer contract, not just release automation.