Readiness gap

The engine versions are mechanically kept together, but current product/package prose has already drifted:

• the workspace and Python package are at 0.12.0;
• sdk/python/README.md still says the project is at “v0.2”;
• CONTRIBUTING.md says the Python SDK “will become PyO3/maturin bindings” even though it already is;
• the same file calls the JavaScript SDK a placeholder even though the npm launcher is a supported install path.

None of these break the engine, but stale current-state documentation makes a pre-alpha project look less reliable and can send adopters down obsolete setup paths.

Acceptance criteria

• Declare one canonical source for the current version and maturity status.
• Generate package-facing descriptions from a maintained source where practical, rather than copying current-version prose.
• Update sdk/python/README.md and CONTRIBUTING.md to describe the shipping PyO3 wheel and npm launcher accurately.
• Extend the existing versions agree job, or add a docs-truth check, so stale hard-coded current versions and known placeholder/future-tense statements fail CI.
• Add a release checklist or automation that verifies the website, GitHub README, PyPI and npm all describe the same current release and installation paths.
• Smoke-test the artifacts installed from the registries—not from the checkout—using pip install flowproof and npx flowproof --version.
• Exercise at least Linux, Windows and macOS ARM64 artifact resolution before announcing a release.
• Keep historical changelog versions exempt from current-version checks.