Feature request: support WASM js-string-builtins proposal

[katis]

Summary

The V8 build behind workerd supports the js-string-builtins proposal (shipped by default in V8 / Chrome
≥130), but there's no way to enable it for Wasm loaded as a Worker module. The builtins require a per-module compile-time opt-in (CompileTimeImports), and neither of workerd's module-compilation paths supply it.
Request: a way to enable builtins: ['js-string'] for module-imported Wasm (CompiledWasm modules and Worker Loader { wasm } modules).

Background

The proposal is opt-in per module. From JS that's WebAssembly.compile(bytes, { builtins: ['js-string'] }); the engine then resolves imports from the reserved wasm:js-string namespace as native builtins instead of treating them as ordinary imports.

Problem

In workerd:

1. Runtime WebAssembly.compile(bytes, …) the only JS API that accepts the builtins opt-in is blocked: CompileError: WebAssembly.compile(): Wasm code generation disallowed by embedder.

2. Module-imported Wasm is compiled via the C++ API, which passes no CompileTimeImports:

   // src/workerd/jsg/modules.c++ — compileWasmModule
   return jsg::check(v8::WasmModuleObject::Compile(
       js.v8Isolate, v8::MemorySpan<const uint8_t>(code.begin(), code.size())));

So a .wasm module that imports wasm:js-string has those imports treated as ordinary (unresolved) imports — they can only be satisfied with hand-written JS glue functions, which defeats the purpose of the proposal (native, inlinable string ops with no JS round-trip).

Repro (verified on deployed Workers)

A CompiledWasm module importing wasm:js-string length (func (param externref) (result i32)), re-exported as len:

// instantiate with empty imports — expecting native builtins
await WebAssembly.instantiate(lengthModule, {});
// → TypeError: WebAssembly.instantiate(): Import #0 "wasm:js-string": module is not an object or function

// only the JS-glue fallback works:
await WebAssembly.instantiate(lengthModule, { "wasm:js-string": { length: (s) => s.length } });
// → ok, len("hello") === 5

WebAssembly.validate(bytes, { builtins: ['js-string'] }) does honor the option (the namespace is recognized and type-checked), confirming the feature is present in the engine — it just can't be turned on for module compilation.

Proposed solution

• Thread a CompileTimeImports (with js-string enabled) into the module-compilation path — compileWasmModule / compileWasmGlobal — gated behind a compatibility flag

Use case

I'm building a language that compiles to WASM and runs also on CF workers, Strings are currently a WasmGC byte array; js-string-builtins would let us back them with JS strings and get native length/concat/compare/substring without JS glue — but there's no path to enable it today.

[hustcer]

We need this feature too, please

[guybedford]

Could you share further details of how you are using the proposal to help us motivate this work?