Add boomslang-py: Python host package (python-in-python)

[zklapow]

Why

Boomslang's sandboxed CPython-3.14-WASM runtime is currently only embeddable from Java (Chicory) or Rust (Wasmtime). Python programs that want to execute untrusted Python — agent code execution, user-supplied scripts, notebooks — have no way to use it. Inspired by simonw/micropython-wasm, this adds a self-contained Python wheel that bundles the entire WASM runtime, so pip install + Sandbox().execute(code) gives sandboxed python-in-python with numpy/pandas/pydantic preloaded, no JVM required.

What

• boomslang-py/ — pure-Python package (only dep: wasmtime) exposing Sandbox: execute, resource limits (timeout via epoch interruption, memory, output caps), poison/reset, /work//lib mounts, stdin, bytecode compile/load, execute_function, sync and async host functions (ports the AsyncHostRegistry v1 wire protocol).
• Large host-call results — the guest bridge's fixed 1 MiB result buffer is transparently bypassed by monkeypatching boomslang_host.call at sandbox bootstrap to fetch parked results in chunks via reserved __result_pending__/__result_chunk__ control calls (no wasm rebuild; degrades to stock behavior under the Java host).
• CI — new python-wheel job builds the wheel from the existing runtime artifact, tests against the installed wheel, and the release job ships it as a GitHub release asset (no PyPI).
• Docs — package README + README/CLAUDE.md sections, including the load-bearing discovery that the guest libc's preopen table is baked in at Wizer time and binds host preopens positionally (fd 3 = /usr, fd 4 = /lib, fd 5 = /work, fd 6 = /tmp) — arbitrary guest mount points are unreachable for any host.

Testing

51 pytest cases executing real guest code (isolation, timeout-poison-reset, concurrency of async handlers, 3 MB host-call results, stdlib read-only enforcement, work-dir roundtrips), run both editable and against the installed 55 MB wheel in a clean venv: all green. Local flow: just fetch-main-wasm && just python-test.