Make the default PyPI surface resolve to the supported 2.0 line

[rmcdaniel]

Problem

The exact Durable Workflow 2.0 release-candidate pages and JSON metadata are current, but PyPI's unversioned project surface still selects 0.4.106 because it is the newest non-prerelease release. That page advertises stale readiness and capability text, and a plain pip install durable-workflow can resolve to the unsupported 0.x line.

This has already produced a credible external evaluation claiming that 2.0 is still beta/pre-RC and that server-routed query/update behavior is unfinished, even though the exact current RC metadata is correct. Exact-version publication checks do not cover what an evaluator or an unpinned installer sees.

Acceptance criteria

• Keep all historical files and release records immutable; mark unsupported pre-2.0 final releases as yanked rather than deleting them.
• Verify through PyPI's project and exact-version JSON APIs that the unversioned project surface no longer presents an unsupported 0.x release as the current product and that the current 2.0 RC metadata is accurate.
• In a clean isolated Python environment, prove the documented install command resolves to the supported 2.0 line. If prerelease installer semantics require an explicit --pre or version range before stable 2.0, make that command consistent across the PyPI README, API reference, and main 2.0 quickstart.
• Add an automated registry-default audit that checks the unversioned PyPI JSON surface as well as the exact published version. Do not depend on rendered PyPI HTML or weaken exact artifact/source verification.
• Report the yanked version set, selected install version, and confirming public URLs on this issue before closing.
• Do not publish a synthetic stable 2.0 release to satisfy this issue; stable 2.0 remains separately release-authorized.

The release-management UI action, if PyPI provides no authenticated yank API, may be performed by the project owner after the automated checks and exact version list are ready. The implementation must first do every automatable step and then provide one exact bounded action, not a general handoff.