docs: add public proofs and scenario recipes for the five promoted 3.1 diagram types #916

Problem and value

Archify 3.1.0 promotes ERD, Class, Tree, Timeline and Waterfall, but the public gallery/recipe inventory still principally demonstrates the legacy modes plus ERD. The package already contains examples for the new renderers; visitors need checked, explorable examples that explain when to choose them. Release preparation (#914, #915) made the supported inventory explicit without inventing missing gallery proofs.

Scope

Reuse the shipped example sources where they tell a clear story. Add a bounded scenario and public proof for Class, Tree, Timeline and Waterfall; assess the existing ERD/database-schema proof and reuse it rather than duplicating it. Keep canonical scenario data in archify/recipes/scenarios.mjs and feed existing gallery generation/presentation machinery. This is showcase/authoring work, not a renderer feature or redesign.

Useful candidate stories: interfaces and implementations (Class), repository/module hierarchy (Tree), a documented change history (Timeline), and request phase timings (Waterfall). Final scenarios should answer one concrete question each.

Acceptance

• Each of the five promoted types has an identifiable public example, editable typed JSON, explorable HTML, a concise question, and a copyable starter prompt.
• Every new recipe has equivalent English/Chinese copy, evidence requirements and when-not-to-use guidance. Existing ERD proof remains reusable.
• Validate/deliver/provenance/browser gates pass using the implementation revision. Separate automated receipts from human screenshot review.
• Inspect matched light/dark captures at 1440×900 and a narrow reader viewport; inspect routing, text and controls rather than treating a green receipt as visual acceptance.
• Timeline dates cite a source when factual. Waterfall durations cite measurements when measured; synthetic values are explicitly labelled illustrative. Conceptual ERD models are distinguished from physical schemas.
• Use public/redacted fixture material. No local project paths, private repository content or unsupported performance claims enter public artifacts.
• Generated manifest, links, example HTML and applicable canonical archive checks remain fresh. Record source revision and regeneration commands.

Follow-up

This supplies the verified assets/recipe IDs consumed by the README (#917) and website (#918) expansion tasks. Integrate through dev; follow the normal stable promotion process rather than changing the immutable 3.1.0 tag.