Release readiness: make package and documentation metadata move with the engine version

[AminChirazi]

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.

[AminChirazi]

Split into atomic follow-ups after autonomous eligibility review:

• docs: describe the shipping Python binding and npm launcher accurately #380 — documentation-only correction for CONTRIBUTING.md and sdk/python/README.md. Deliberately left without ready; maintainers must authorize scheduling separately.
• Release governance: define canonical product metadata and make documentation drift fail CI #381 — canonical metadata policy and docs-truth CI enforcement. needs-human because it requires a policy decision and constitution-protected workflow changes.
• Release assurance: validate registry-installed FlowProof on Linux, Windows, and macOS ARM64 #382 — exact-version PyPI/npm installation validation across Linux, Windows, and macOS ARM64. needs-human because it requires registries, hosted runners, release coordination, and protected workflow changes.

Dependency order: #380 before #381. #382 can be developed independently but only produces release evidence after the exact version exists in both registries.

Keeping #377 open as the umbrella and labeling it needs-human; a docs-only partial change must not claim to close the full release-readiness scope.