feat: PIC package composition (level 2) — N packages, one memory, CompositionBuilder API

[colinrozzi]

PIC package composition (level 2) — N packages, one memory, CompositionBuilder API

Package A imports and calls package B while sharing one linear memory (the level-2 spec, #37), on the 0.8.x PIC loader. Unlike the level-1 CompositionBuilder (separate memories, a cross-memory byte-copy bridge), a consumer's import is wired to a provider's export in the same memory — no copy.

The API

let mut comp = PicCompositionBuilder::new(&engine)
    .add_package("doubler", doubler_wasm)
    .add_package("adder", adder_wasm)
    .wire("adder", "math", "double", "doubler", "double")
    .build()?;
comp.call("adder", "process", &Value::S64(5))?; // → 11, adder called doubler in shared memory

How

• src/runtime/pic_composition.rs: build() topologically instantiates each PIC package at a disjoint __memory_base + stack + table_base in one shared Memory, on one shared in-wasm allocator. Each cross-package import is wired via a thin shim that calls the provider's export in-memory and re-labels the ABI status (0→1) so the consumer's __import_impl frees the provider's result buffer (same shared allocator). call() frees its own buffers — no per-call leak.
• packages/{doubler-pic,adder-pic}: PIC builds (originals stay non-PIC for the level-1 tests).

Tests

• correctness — adder.process(5)=11 (and more) via the real PicCompositionBuilder.
• no leak — 40 large (~256 KiB) cross-package returns through the 4 MiB shared heap; a leak would exhaust it in ~15 calls. Freed → all pass.
• mechanism — the hand-rolled loader proof.

pic_composition 16/16; full workspace green; clippy + fmt clean; CI builds the two new fixtures.

Follow-up (level 3): static-merge the (now proven) PIC side modules into one passable .wasm.

🤖 Generated with Claude Code