Explain how production problems shaped each ShakaStack project

[justin808]

Parent: #45

Why

The site currently explains what each project does, but not the more compelling reason the projects exist: ShakaCode encountered recurring production problems and turned the resulting solutions and stewardship into reusable infrastructure.

Proposed change

Add a compact homepage section such as:

Production problems became reusable infrastructure

Map each verified problem to the relevant project:

Production need	Project
Run sophisticated React inside an established Rails application	React on Rails
Keep the Rails JavaScript-bundling path maintained and modern	Shakapacker
Give browser tests access to Rails scenarios, factories, and clean test data	E2E on Rails
Compare performance changes rigorously and catch visual regressions	ShakaPerf
Preserve a Heroku-style delivery workflow on Control Plane	Control Plane Flow

The final copy must distinguish among:

• code genuinely extracted from a production application;
• a project shaped by work across several production applications;
• community stewardship or adoption of an existing Rails path.

Do not force every project into the word “extracted” if its history is different.

ShakaPerf accuracy note

ShakaPerf has been developed over several years from ShakaCode's need to highly optimize Popmenu's React-heavy Rails application. It addressed repeated difficulties such as noisy comparisons, performance hypotheses that did not pay off, complexity that was not justified by measurable gains, pull-request validation, and visual-regression detection.

Acceptance criteria

• Verify the origin/stewardship history of every project with maintainers or public primary sources.
• Use “extracted,” “shaped by,” or “maintained successor” accurately for each project.
• Tell the ShakaPerf origin as a multi-year production need, not a single-event creation story.
• Explain that E2E on Rails verifies behavior while ShakaPerf verifies performance and visual stability.
• Keep the section compact and avoid duplicating the existing Stack explorer.
• Link each row/card to the relevant project or deeper evidence.
• Add copy regression coverage and complete the repository's required validation.