fix(cli): #1723 gate import.meta.url transform on js content-type so wasm skips acorn

[jstockdi]

Related Issue

Resolves #1723

Documentation

N/A — no user-facing documentation changes. (The supported wasm pattern, new URL("./x.wasm", import.meta.url), is unchanged; this PR only fixes the crash for the unsupported direct-import syntax.)

Summary of Changes

1. Gate the greenwood-import-meta-url Rollup transform so it only parses a module with acorn when the final served response content-type is JavaScript. Binary resources (.wasm, and by extension .png / .woff2 / etc.) are no longer fed to the JS parser, so greenwood build no longer crashes with a cryptic acorn SyntaxError attributed to internal plugin code.
   • The previous canTransform flag was set true whenever any resource plugin served the module; because the node-modules resource plugin serves any existing file as text/javascript, wasm binaries slipped through. The fix keeps canTransform and additionally requires response.headers.get("content-type") to contain text/javascript before parsing.
2. Fix an operator-precedence bug on the neighboring content-type check (rollup.config.js:366): response?.headers?.get("content-type") || "".indexOf("text/javascript") >= 0 was truthy for any content-type; parenthesized to (response?.headers?.get("content-type") || "").indexOf("text/javascript") >= 0 so it actually tests that the content-type contains text/javascript.
3. Add regression tests under packages/cli/test/cases/:
   • build.default.wasm-import-meta-url — the supported new URL("./add.wasm", import.meta.url) pattern: asserts the build succeeds, emits exactly one content-hashed .wasm asset that is byte-identical to the source, and that the bundled script references the hashed filename.
   • build.default.wasm-import-invalid — an unsupported direct import ... from "./add.wasm": asserts the build still fails (this syntax is not supported), but no longer crashes with the acorn SyntaxError from the greenwood-import-meta-url plugin. Post-fix the direct import surfaces a clear, Rollup-native PARSE_ERROR instead of a stack pointing at Greenwood internals.

Resulting behavior for a direct .wasm import

The direct import x from "./x.wasm" syntax remains unsupported and the build fails, but the failure is now a Rollup-native PARSE_ERROR (Rollup parsing the served wasm bytes as a module) rather than the misleading acorn crash inside greenwood-import-meta-url. Users should use the supported new URL("./x.wasm", import.meta.url) + fetch / WebAssembly.instantiateStreaming pattern, which content-hashes the asset correctly.

Breaking changes

None. The supported new URL(...) wasm path is unchanged (verified byte-for-byte), and legitimate JavaScript modules still transform normally (their served content-type is text/javascript).