Make the 2.0 quickstart install tuple explicit and current

[rmcdaniel]

Problem

The live 2.0 quickstart names Python SDK 2.0.0-rc.20 as the current release immediately above a runnable command that installs 2.0.0-rc.8. Its active PHP, Rust, Workflow, and Server commands likewise use older prereleases without identifying whether they are historical, current, or the last jointly qualified compatibility tuple.

Independent component versions are intentional, but an evaluator cannot tell which exact artifacts to install or why the current package authority differs from the runnable command. This recreates a stale-version impression even though the old 0.x prerelease guidance has been removed.

Acceptance criteria

• Give the runnable quickstart tuple one explicit meaning: either the current exact qualified tuple or a clearly dated last-qualified compatibility tuple.
• Do not call one component release current immediately beside a command that installs a different release without explaining the distinction.
• Keep independent component versions; do not invent a synthetic shared version.
• Derive all active PHP, Python, Rust, Server, CLI, Workflow, and Waterline install identities from one versioned authority and its verified release or conformance handoff.
• Make accepted release handoffs refresh active install commands without manual literal edits while retaining immutable historical evidence as history.
• Add structural checks for authority and rendered-command coherence without freezing ordinary documentation prose.
• Verify the deployed quickstart and package links after publication.

Delete when

Delete when a first-time reader can identify and install the intended qualified 2.0 tuple from the live quickstart without encountering contradictory current and runnable versions.