vm2: NodeVM zlib Buffers expose pooled host memory across the VM boundary

## Summary When an application explicitly exposes Node's `zlib` module through vm2's `NodeVM` builtin allowlist, an untrusted guest can obtain a pool-backed host `Buffer` from `zlib.deflateSync`, create a full-width view of its backing `ArrayBuffer`, read bytes outside the compressed result, and flip a byte in an unrelated host buffer. The pinned vm2 revision reproduces disclosure and host-memory modification, while a sandbox-local `Buffer` control remains exact-size and non-mutating. ## Technical Details `NodeVM` accepts `require: { builtin: ['zlib'] }`. The builtin resolver reaches `addDefaultBuiltin` in `lib/builtin.js`, where the host module is exposed through the generic readonly wrapper. `zlib.deflateSync` returns a Node `Buffer`; for a small result, that buffer can use Node's shared pool, whose `.buffer` is the complete pool rather than only the logical result slice. The guest can therefore call `Buffer.from(result.buffer, 0, result.buffer.byteLength)` and inspect or modify pooled bytes outside `result`. The relevant isolation invariant is that every `Buffer` crossing into the sandbox owns its complete backing store: `byteOffset === 0` and `buffer.byteLength === length`. vm2's `depoolBuffer` implementation applies that rule to sandbox-facing `Buffer` factories, but the generic host-builtin return path does not apply it to the `Buffer` returned by `zlib`. The precondition is an embedder that deliberately allowlists `zlib`; applications that do not expose this builtin ar