W-23517830: Add isolated-process test for bad-library-path initialization in the DataWeave Node.js binding

[mlischetti]

What

A bad/nonexistent dwlib path makes initialize() throw a DataWeaveError only as the first native init in a process — the runtime is loaded process-globally / ref-counted, so once any good init has run, a later bad-path init is tolerated. That made it order-dependent (flaky) in the shared lane.

Approach

Run it in a dedicated child process, making it order- and vitest-pool-independent:

• tests/integration/fixtures/bad-lib-init.cjs — child fixture that requires the built dist/ entry, asserts the DataWeaveError, and signals via stdout sentinel + exit code (no-throw / wrong-error / native crash all surface as a non-zero child exit).
• tests/integration/init-bad-path.test.ts — spawns the fixture with execFileSync (throws on non-zero exit) and asserts the OK:DataWeaveError sentinel; guards on the built entry existing.
• edge-cases.test.ts — NOTE updated to point at the new test.

Note: vitest's default forks pool already isolates per file, so a plain test file would pass today — but relying on that would reintroduce the exact hidden process-global coupling this test guards against. The spawned child is robust to pool/config changes.

Testing

• tsc --noEmit clean
• npm run test:unit → 70 passed
• npm run test:integration → 35 passed, deterministic across repeated runs

🤖 Generated with Claude Code