feat(frontend): landing page refresh — value props grid and live demo (#356)

[Obiajulu-gif]

Summary

Adds two new sections between the stats bar and the specialist-agents grid:

• ValuePropsSection: a 4-card grid (on-chain discovery, autonomous orchestration, instant Stellar payments, composable workflows), each with an icon, animating in on scroll (framer-motion whileInView, staggered).
• LiveDemoSection: pairs a fixed example workflow walkthrough (the market-entry-report scenario already described in the README's demo section, presented as a staggered Research → Risk → Report reveal) with a "Live Network Activity" panel showing real numbers fetched from GET /api/stats (total tasks, active agents, XLM paid out, uptime) — the only public, no-wallet-required endpoint available (getRecentTasks needs a wallet address, so isn't usable for an anonymous landing page visitor). Loading and error states included.

Both new sections plus the existing StatsBar/SpecialistAgentsSection animate on scroll via framer-motion's whileInView; Hero animates in on load (it's already in the viewport on page load, so whileInView isn't the right trigger there — it uses a staggered animate="visible" instead).

Necessary prerequisite: Hero.tsx had mismatched JSX tags and didn't compile

Hero.tsx opened <motion.section>/<motion.div>/<h1>/<p> but closed several of them with the wrong tag (</section>, </motion.div> closing a plain <div>, </motion.h1> closing a plain <h1>, etc.) — a different corruption pattern than the "two versions concatenated" bug found across backend/ this session (see #443/#460/#461/#463), but equally blocking: the file was invalid JSX and neither Hero.test.tsx nor the landing page itself could ever have compiled as committed. Fixed by making every motion.* tag consistent (open and close both motion.* or both plain) and importing motion/defining containerVariants, which were also missing. While in there, converted the hero's per-element animationDelay + CSS slide-up class approach to framer-motion's staggerChildren, which is what the rest of the landing page already uses.

Also added an IntersectionObserver mock to vitest.setup.ts — jsdom doesn't provide one, and framer-motion's whileInView (used throughout this page, including the pre-existing StatsBar/SpecialistAgentsSection) needs it. No landing-page test had ever actually mounted a whileInView component before (Hero.tsx didn't compile, and StatsBar/SpecialistAgentsSection have no test files), so this gap was never hit until now.

Acceptance Criteria

• Hero and sections animate on scroll
• Demo section shows a real orchestrated workflow result from API — via the live GET /api/stats panel; the step-by-step walkthrough itself is a labeled, fixed example (there's no public "get a random real task" endpoint to pull a literal historical run from without requiring a connected wallet), paired with real aggregate numbers from actual completed workflows.

Test plan

npx vitest run src/components/landing/ — 9/9 passing (3 Hero, 2 ValuePropsSection, 4 LiveDemoSection: immediate render of the example steps without waiting on the API, loading state, real stats rendered once loaded, graceful fallback on API failure).

npx tsc --noEmit reports zero errors in any file this PR touches. It does surface the same JSX-tag-mismatch corruption pattern in three unrelated pre-existing files (App.tsx, components/wallet/SendXLMForm.tsx, context/ToastContext.tsx) — out of scope here, flagging separately.

Closes #356

[drips-wave]

@Obiajulu-gif Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@Obiajulu-gif is attempting to deploy a commit to the Jaja's projects Team on Vercel.

A member of the Team first needs to authorize it.