Release packaging: one .wasm per engine and plain native files

As 0.0.26 ships it: each WebAssembly engine is one .wasm carrying its own bindings, one loader runs any of them in a default-deny sandbox, and native downloads are plain files, Linux arm64 and armv7 included.

0.0.26 changes what a release ships. Every WebAssembly engine is a single file, zipp-<version>-javascript.wasm, -javascript-lite.wasm, -javascript-python.wasm or -javascript-python-base.wasm, beside zipp-<version>-torch-package.wasm. Each engine carries the JavaScript bindings generated for exactly that build in a custom section, with a record of its version, commit and variant, so a glue file can no longer meet another build's module. One loader, zipp.mjs, reads that record and those bindings and runs any of the engines in a page, a Worker, Node, Deno or Bun. It ships in zipp-<version>-wasm-embed-kit.zip with its types, the host SDK, the GPU lab, the docs and examples.

A sandbox made by that loader starts with no storage, no files, no network and no host functions, and each is granted explicitly: a private in-memory localStorage, a map of files to read (and to write, if allowed), a fetch that reaches only listed origins or URL prefixes and sends no cookies, and named host functions. An instruction budget stops runaway computation inside the engine, and each sandbox runs in its own Worker by default, which a time limit terminates. Native downloads are plain files: a Windows portable .exe, a Windows .msi that installs per user and adds zipp to the user's PATH, and Linux binaries for x86-64, arm64 and armv7. This site gains a sandbox playground for the new loader, which runs the 0.0.26 JavaScript engine.