Present one coherent Durable Workflow 2.0 product train

[rmcdaniel]

The current public tuple exposes unrelated pre-1.0 versions for the server, CLI, and PHP, Python, and Rust SDKs alongside 2.0.0-beta.1 engine packages. Historical feature-introduction version guidance also makes users choose among prerelease generations. Beta should present one supported 2.0 baseline.

Goal

A user chooses Durable Workflow 2.0 once, then installs a documented compatible server, CLI, engine, operator, and language SDK tuple without reasoning about which alpha introduced a baseline feature.

Acceptance criteria

• Define and publish one versioning and compatibility policy for the server, CLI, Workflow, Waterline, and PHP, Python, and Rust SDKs.
• Current beta artifacts and examples use a coherent 2.0 prerelease train or an equally explicit mapping that exposes only one supported 2.0 choice to users.
• Feature-introduction matrices for capabilities already in the 2.0 baseline are removed from user guidance.
• Older alpha artifacts remain historical and are yanked or de-emphasized where registries permit without rewriting immutable release history.
• New capabilities added after the 2.0 baseline follow ordinary compatible version progression.
• Package metadata, generated docs, release notes, installation commands, and cross-language examples agree on the supported tuple.
• A clean-machine install and published-artifact conformance pass proves the resulting tuple across PHP, Python, and Rust.
• No compatibility shim between earlier 2.0 alpha or beta implementations is added.

Required source targets

durable-workflow/.github@main
durable-workflow/cli@main
durable-workflow/durable-workflow.github.io@main
durable-workflow/sample-app@main
durable-workflow/sdk-php@main
durable-workflow/sdk-python@main
durable-workflow/sdk-rust@main
durable-workflow/server@main
durable-workflow/waterline@v2
durable-workflow/workflow@v2

[rmcdaniel]

Completed. The supported 2.0 surface now uses one coherent prerelease line across Workflow, Waterline, Server, CLI, and the PHP, Python, and Rust SDKs; public release surfaces are identity-verified, current published-artifact conformance is 29/29, and prerelease generations are not supported through compatibility shims. Future train advances are ordinary current-release work, not a reason to keep this bootstrap umbrella open.