Story: Make roadmaps the library landing pages and link documented versions #131

Parent Epic: #125
Depends on: #126 and #127

As a documentation reader,
I want each library's landing page to show its roadmap and link each documented branch to its version landing page,
so that I can understand the library's plans and open the relevant version documentation directly.

Context

The preceding Stories generate a roadmap SVG and support table from library JSON configuration. This Story makes that roadmap the library landing page.

For each library, remove the existing library-level docs/<library>/index.md and rename docs/<library>/roadmap.md to docs/<library>/index.md. The roadmap generator then replaces the body of the new library index during the build, rather than targeting roadmap.md. Version landing pages such as docs/<library>/v2/index.md remain available.

This Story supersedes the earlier Stories' assumption that the roadmap is published on a separate roadmap.md page.

Acceptance Criteria

• Every library in scope uses docs/<library>/index.md as its roadmap and landing page.
• The previous library-level index is removed and the existing roadmap is renamed to that index; no separate library-level roadmap.md remains.
• Version-level index pages, including docs/<library>/v2/index.md, are preserved.
• When roadmap configuration is populated, the build-time roadmap script replaces the body of the library's index.md with the generated timeline and support table, rather than updating roadmap.md.
• The generated body replaces previous body content rather than appending to it; repeated builds do not duplicate content.
• Required YAML front matter is preserved, with a valid title and description appropriate to the library landing page.
• A missing or unpopulated configuration is treated as a roadmap that has not yet been established. This includes an empty configuration file, an empty JSON object, or an otherwise valid configuration with no branches.
• In that case, the index body displays the default English text: “The roadmap for this library has not been established yet.” No timeline or support table is generated for that library.
• A populated branch list whose dates are all unannounced remains a configured roadmap and uses the previously defined unannounced-data behavior.
• Malformed non-empty JSON and populated but invalid configuration are reported as configuration errors rather than silently treated as an unestablished roadmap.
• In the table, each branch with a corresponding documented major-version landing page is a link to that page: for example, 2.x links to v2/index.md in portable Markdown and its corresponding HTML resource on the website.
• If a branch has no corresponding version landing page, its label remains plain text; no broken link or invented documentation page is generated.
• Navigation, internal links, and generated documentation-version status messages that previously linked to roadmap.md point to the library index instead.
• Both HTML and portable Markdown publish the new library landing page with working image references and version links.

Constraints

• Scope the removal to library-level index pages being replaced; do not remove version-level or unrelated index pages.
• Retain build-time generation, a shared data source for SVG and table, site colors, and absolute dates as approved in Story: Generate SVG support timelines with Node.js #126 and Story: Integrate support timelines and tables into every library roadmap #127.
• Use Markdown sources without introducing MDX or raw HTML.
• Follow the repository's portable Markdown publication contract and explicit HTML resource paths.
• Do not change Packagist-based version classification or invent support dates, releases, or PHP compatibility.

Definition of Done

The project's common Definition of Done applies.

• Inventory affected library index and roadmap pages and verify the complete migration.
• Tests cover configured roadmap generation, missing and empty configurations, no branches, unannounced dates, malformed or invalid configuration, front-matter preservation, and repeat-build behavior.
• Tests cover branch-to-version links, missing version landing pages, navigation, and documentation-version status links in both HTML and portable Markdown.
• npm test, npm run build, and applicable Markdown lint checks pass with no broken internal or image references.
• Representative populated and unestablished library landing pages are checked visually in both themes and on mobile.
• Maintainer documentation explains the new generation target and default behavior.
• Common composer test-local and composer quality checks apply only if defined in the repository; otherwise record them as not applicable to this documentation site.