Function assertRequiredWasmExports

Reject a module that imported and initialised fine but predates one of the REQUIRED_WASM_EXPORTS kernels. The list itself lives in ./required-exports.ts because the vitest global setup shares it; see the comment there for why it is a separate module.

make build-wasm is the fix for a genuinely stale build, but the two caller classes react to a failed check very differently:

• initWasm catches it and enters the normal TypeScript fallback path, which is correct but slower;
• the test/benchmark loader (src/tests/helpers/wasm-artifact.ts) lets it throw — there is no fallback there, and failing loudly by name is the whole point.

initWasm calls this before handing the module out, so the runtime path is covered. Tests, benchmarks and tools that want the compiled kernels load the built artifact themselves — await import('.../public/wasm/ luxar_wasm.js') + initSync(), bypassing initWasm — and get this check from the ONE loader they all share, src/tests/helpers/wasm-artifact.ts. That loader calls it before the as unknown as WasmModule cast (the double cast promises the entire interface while the artifact may be missing half of it, so a stale gitignored build otherwise surfaces as an opaque "x is not a function" from whichever kernel assertion runs first) and OUTSIDE the catch that downgrades a load failure to a skip (inside it, the named message would be swallowed too). direct-import-guard.test.ts pins exactly one rule to keep that true: no source outside that helper may load the artifact itself — it fails on any other .ts under src/, tools/ or scripts/ that both mentions luxar_wasm.js and calls initSync(.

initWasm is the one deliberate exception to the placement rule: it calls this INSIDE the try whose catch returns a TypeScriptFallback, because entering the documented fallback is the right response to a stale build on the runtime path. The guard test exempts this module for that reason.