[v0.2] Replace internal phase labels with versioned capability terminology

[Teakowa]

Release coordination: #135

Goal

Keep internal planning shorthand out of the product/repository vocabulary so release progress is expressed by concrete capabilities and semantic versions rather than an ever-increasing phase counter.

Scope

• Remove internal phase-number planning labels from active/living code comments, documentation, open issue/PR text, and release-facing material where they are still used as current product terminology.
• Replace them with concrete feature names, issue references, or actual release targets.
• Point active roadmap/architecture material to Roadmap to v1.0: stable Workshop tooling platform #134 where a release/readiness contract is needed.
• Audit the code/docs landed by merged PR M14: validated source editing across Wright frontends (autonomous checkpoint) #133 and remove persistent current-roadmap phase terminology through normal follow-up changes; do not rewrite its historical PR/commit record.
• Establish the convention that new issues and PRs use capability/version terminology.

Historical boundary

Do not rewrite git history, closed historical issues/PR discussions, or archival records solely for terminology cleanup. Historical references may remain when needed for provenance, but they are not the current readiness model.

Acceptance criteria

• Living code/docs and active release-facing work no longer use internal phase numbers as the roadmap model.
• Roadmap to v1.0: stable Workshop tooling platform #134 is the normative pre-1.0 capability/readiness roadmap.
• Closed historical work remains intact rather than being cosmetically rewritten.
• New planning work uses feature names and concrete versions where appropriate.