[www] Add a host-aware multi-file code example component

Goal

Add a reusable documentation component that can present multiple files and multiple host variants for one example. Its initial host should follow the website-wide adapter preference.

Typical examples may need separate Web Components, React, and Vue variants, and each variant may contain more than one file.

Current state

The repository contains useful adjacent capabilities, but they are not yet a reusable multi-file code example system:

• Ordinary Markdown code blocks primarily represent one snippet.
• apps/www/src/components/PrototypePreviewer/CodePanel.astro accepts one code string and one lang, with highlighting, copy, and expand behavior.
• apps/www/src/components/PrototypePreviewer/PrototypePreviewer.astro can prepare different code snippets for different runtimes.
• apps/www/src/components/override/AdapterSelect.astro persists the global preferred-prototypes-adapter value and dispatches proto-adapter:change.

These pieces are not currently unified for ordinary MDX content, and the previewer's runtime code is not a general multi-file model.

A possible input shape is:

{
  wc: [
    { path: 'index.html', lang: 'html', code: '...' },
    { path: 'main.ts', lang: 'ts', code: '...' }
  ],
  react: [
    { path: 'App.tsx', lang: 'tsx', code: '...' }
  ]
}

Host selection and file selection are separate dimensions and should not be flattened into one ambiguous tab row.

Suggested interaction model

• On initial display, use the global adapter preference when that host variant exists.
• If the preferred host is unavailable, fall back to the first available host without changing the global preference.
• When the global adapter changes later, examples that support it should follow that change.
• Switching the host inside one code example should remain local to that example and should not overwrite the site-wide preference.
• File tabs select the current file within the active host.
• Reuse the existing Shiki, copy, and expansion behavior where practical.

If implementation evidence reveals a conflict in this interaction model, raise it in the PR instead of silently inventing a second global preference mechanism.

Suggested workflow

1. Propose the smallest Astro/MDX-facing data model that covers host variants and files.
2. Reuse or extract the existing Shiki/highlight and copy behavior.
3. Implement accessible host and file selection.
4. Connect initial and subsequent host selection to the existing adapter preference/event.
5. Add or migrate one real documentation example containing at least two hosts and two files.
6. Verify desktop, narrow screens, and both themes.

AI-assisted API exploration, component implementation, and example migration are welcome. The contributor must manually verify tabs, keyboard behavior, copied content, global-adapter synchronization, and narrow-screen scrolling.

Acceptance criteria

• A reusable component can be invoked from Astro/MDX documentation.
• One example can contain at least two host variants and at least two files.
• Initial host selection follows the global adapter preference when supported.
• Compatible examples respond to later global adapter changes.
• Local host switching does not overwrite the site-wide preference.
• Host and file tabs expose appropriate tab semantics and keyboard behavior.
• Each file displays its path/name, correct syntax highlighting, and a copy action.
• Long code scrolls inside the code region on narrow screens.
• Active states and code remain readable in light and dark themes.
• At least one real documentation example proves the integration.
• corepack pnpm@10.32.1 --filter apps-www build passes.

Out of scope

• An online editor or playground.
• Executing or compiling user-edited code.
• Diff views or line-level review features.
• Migrating every existing code block in one change.
• Changing Proto UI host or adapter contracts.