Parents: #473, #495 Related: #474
Problem
The pinned Bun/Home JSC__JSModuleLoader__loadAndEvaluateModule and JSModuleLoader__import boundary decodes a BunString into an engine StringData value, then passes decoded.asStr() to Context.loadAndEvaluateModule. With flat Latin-1 storage active, asStr() is the physical one-byte-per-code-unit image, not canonical WTF-8. A semantic specifier such as /virtual/café.js is therefore looked up as /virtual/caf\xE9.js, missing the exact module registry entry and potentially reaching filesystem resolution with malformed bytes.
Scope
- Consume the decoded module-name StringData as canonical WTF-8 before registry or filesystem resolution.
- Add a private-ABI fixture that registers a non-ASCII Latin-1 virtual module and imports it through both exported BunString entry points.
- Preserve the existing ASCII zero-conversion path, Promise identity/cache behavior, null-input exception behavior, ownership, OOM propagation, and pinned symbol/layout contract.
No-workaround rules
- No ASCII-only restriction, lossy replacement, alternate registry alias, duplicate module registration, fixture-specific recognition, or fallback to the physical byte image.
- Do not change Promise, microtask, queue, job, or module-registry scheduling semantics.
Acceptance
- The exact old physical-byte path fails the new fixture and both corrected exports fulfill with the already-instantiated namespace.
- Repeated ASCII and Latin-1 imports preserve namespace identity and do not re-evaluate the module.
- Home private-ABI audit and Debug/ReleaseSafe/TSan behavior fixtures pass with no ABI inventory drift.
- Full units remain green; applicable Test262 impact is recorded exactly.