Website: revamp and improve the landing page #37

Website: revamp the landing page

The landing page (src/app/page.tsx) is thin. It renders only Hero → Features → Community → FAQ, so a visitor never sees the components working, never sees what's in the library, and gets no clear path to contributing. This issue covers a revamp that makes the page show the product instead of describing it.

Current problems

• No live components. The hero and features show code snippets only. Nothing on the page can be clicked, so you can't try the LanguageSwitcher, PhoneInput or NavBar.
• Unused sections. components.tsx (~700 lines), editing.tsx, getting-started.tsx and contribute.tsx in src/components/landing/ are not imported anywhere. Either use them in the new layout or delete them.
• Copy promises things that don't exist yet. The features grid advertises "Searchable locale pickers" (no such component yet, see Component: Locale Picker #33). The FAQ says components are "used in production apps worldwide". Copy should match what actually ships.
• No component catalogue. There's no section listing the available components with links to their docs.
• Weak contributor funnel. For a community-built library there's no section that points to good first issues or explains the contribution flow.
• Markup: Hero renders its own <main> inside the page's <main>, which is invalid HTML and confuses screen readers.

Proposed structure

1. Hero: clear headline and subhead, install command with a copy button, primary CTA (Get started) and secondary CTA (Browse components), and a live, interactive demo (for example a LanguageSwitcher that re-renders a sample UI in the chosen language, including RTL for Arabic or Hebrew).
2. Component showcase: a grid of every shipped component, each a small live preview linking to its docs page. Build it from the registry (src/registry/registry.ts) so new components appear automatically.
3. Why Elements: 3–4 concise value props (shadcn-style ownership, no framework lock-in, RTL and locale-aware, accessible), with no claims the code doesn't back up.
4. Works with your i18n stack: short snippets showing the switcher wired to next-intl, react-i18next and react-intl.
5. Install in two ways: npm package vs shadcn add / npx @babelize/elements add, in tabs.
6. Contribute: how the flow works plus links to open good first issues; reuse or redesign contribute.tsx.
7. Community + FAQ (trimmed) → Footer.

Design and quality requirements

• Keep the current dark visual identity (emerald accent); stay consistent with the docs site
• Responsive down to 360px wide, with no horizontal scroll
• Respect prefers-reduced-motion for all motion animations
• Accessible: semantic landmarks (one <main>), heading order, visible focus states, AA contrast
• Performance: Lighthouse ≥ 90 for Performance, Accessibility, Best Practices and SEO on mobile. Load demos lazily below the fold, and don't load heavy client JS just for decoration.
• Server components by default; "use client" only for interactive pieces. Read the relevant guide in node_modules/next/dist/docs/ first, because this Next.js version differs from older ones.
• Keep SEO metadata, canonical URL and the OG image working

Out of scope

• GitHub stars counter (tracked in Website: GitHub stars / forks / PRs counter in navbar #36)
• Docs site layout changes

Acceptance

• New section layout live at / with at least one interactive component demo
• Unused landing components either used or removed
• Copy reviewed against what actually ships
• Before/after screenshots (desktop + mobile) and Lighthouse scores in the PR
• bun run lint, format:check, typecheck, test and build pass

Large changes are welcome as a series of smaller PRs (for example hero → showcase → contribute section). Comment here first with the section you're taking so work doesn't overlap.