feat: add newcomer onboarding and Wave browser playground

[LunaStev]

Newcomers can edit and run their first Wave program directly on the homepage, open /playground, or edit and run explicitly marked examples directly inside the documentation. The existing onboarding links and visual layout are retained.

The HTTP/compiler service is implemented in Wave. Playground and Translation share the reusable http/ library for framing, bounded I/O, responses, and connection cleanup. Each service keeps its own routes and process lifecycle; the Go host remains a single application. A minimal Vue/browser bridge executes the generated WASI module in a disposable Worker. Compilation runs in an isolated, unprivileged container; source, time, memory, output, and process limits are enforced. Programs have no filesystem or network host functions.

All platform Wave toolchains are pinned to v0.2.1-pre-beta, including native modules, WaveEditor, public installers, and the translation foundation. Translation bootstrap now verifies and retains the fixed release archive instead of resolving Nightly.

Wave syntax highlighting now follows the pinned compiler in Markdown, source views, and the editable playground. It covers async/await, variants, visibility, explicit memory types, numeric literals, nested comments, and complete Unicode identifiers. Prism automatic DOM rewriting is disabled so highlighting survives direct navigation and refresh.

Documentation uses wave playground fences for embedded editors with Run, Stop, Reset, and inline output. Ordinary Wave fences stay read-only; there is no execution popup or automatic execution. Existing example IDs supply initial stdin; expected output stays in automated test data. The editor displays only actual execution output. A compact toolbar groups Run, Reset, and input settings; input help and execution limits stay collapsed until needed. Idle status stays visually hidden while announcements remain available to assistive technology. After execution starts, a dark terminal panel displays actual output, execution status and exit codes, with distinct error text and keyboard-scrollable output. Seven verified browser-compatible examples are enabled across their translations; live CI checks each with the real Wasm compiler and host.

Validation:

• Full Docker Compose build; platform, gateway, and playground healthy.
• Real compiler/API checks, malformed HTTP framing and deadlines, Wasm execution, Korean stdin/stdout, exit codes, and memory/output bounds.
• Frontend build and documentation, SEO, toolchain, playground, and syntax-highlighting tests; native Wave source-analyzer regression tests.
• Shared HTTP parser tests and standalone example integration tests (binary bodies, HEAD, and 204); both consumers use the shared library.
• Installer shell tests; translation tooling and 11 Wave HTTP integration tests.
• Browser checks on homepage, playground, and documentation: run/stop, diagnostics, runtime timeout, keyboard activation, independent inline editors, reset during execution, English/Korean UI, language changes, and mobile layout.
• Documentation translation/link checks; go test ./internal/web ./internal/platform; whitespace checks.

go test ./... still has three existing failures in internal/document: the Chinese explicit-memory model wording check and two installer-command expectations. The same failures reproduce at the previous PR head b44a4e1; they are not introduced by this change. CI now also builds the playground container and executes the real Wasm output with the browser host. Windows installer validation runs in the existing CI matrix.

Scope: single-file programs with pre-supplied stdin. Incomplete documentation fragments need their surrounding declarations; native/OS-specific examples require a local toolchain. Stop cancels the browser request/Worker; an already accepted server compilation finishes within its own time limit.