vendor or upstream the spinel __wasm__ runtime patch

context

the WASM/edge path is proven (handler → wasm32-wasi → runs under wasmtime,
identical CGI contract). but it required ~38 lines of patches to spinel's
lib/sp_runtime.h, and that patch currently lives ONLY in the scratch dir
(/tmp/webframe-spike/lib-wasm/), not in this repo. so the wasm build is
not reproducible from a clean checkout.

the patch (all platform-shim, zero handler/compiler changes)

1. __wasm__ branch in the platform include block (no ucontext/mman/wait;
   mmap→malloc shim) — mirrors the existing _WIN32 branch
2. WASI libc gaps: stub malloc_trim (no-op), getppid (→0),
   popen/pclose (→null) — all dead code on a handler path
3. fiber stubs: sp_Fiber_* → sp_raise if ever called (WASM has no
   native stack-switching; CGI handlers never create a Fiber)
4. compile flag: -mllvm -wasm-enable-sjlj (spinel uses setjmp/longjmp;
   wasmtime supports the exception-handling proposal)

decision needed

• upstream a clean __wasm__ branch to matz/spinel (best — ~40
  lines, benefits everyone, spinel may want WASI anyway), OR
• vendor the patch in spin (a wasm/ dir + a spin build --wasm
  that applies it to a pinned spinel), OR
• both (carry a patch now, PR upstream later)

deliverable

spin build --wasm handler.rb produces a runnable .wasm from a clean
checkout, with the runtime patch sourced reproducibly. see
docs/spike-hosting.md for the full port writeup.

Read docs/spike-hosting.md first, then inspect the referenced spinel lib/sp_runtime.h patch in /tmp/webframe-spike/lib-wasm/. Decide whether to upstream, vendor, or do both, and verify that spin build --wasm handler.rb produces a runnable .wasm from a clean checkout with the runtime patch sourced reproducibly.