fix(javascript): omit child-process spawns whose command or options Node rejects - #10528

Summary

JavaScript static analysis reported a child-process spawn for node:child_process calls that Node refuses before any child exists: a command it rejects, or an option it validates while normalizing the spawn. These calls no longer produce a childProcessSpawns entry.

Fixes #10522

Problem and expected behavior

Each of these produced one spawn fact on main, and each throws synchronously in Node 24.22.1:

spawn("");                                         // ERR_INVALID_ARG_VALUE
fork(null);                                        // ERR_INVALID_ARG_TYPE
spawn("no\0de");                                   // ERR_INVALID_ARG_VALUE
spawn("node", [], { timeout: -1 });                // ERR_OUT_OF_RANGE
fork("worker.js", [], { serialization: "JSON" });  // ERR_INVALID_ARG_VALUE
execFile("node", [], { shell: 0 }, () => {});      // ERR_INVALID_ARG_TYPE
exec("node", { maxBuffer: -1 }, () => {});         // ERR_OUT_OF_RANGE

Measured rules (all four methods unless noted):

execFile does not forward the boolean flags or serialization to its spawn, and exec replaces a non-string shell, so those methods keep their spawn for the same values.

Change and scope

• rejectsCommand judges the first argument. A spread or computed command stays. fork validates its module as a path, so a URL, a URL-like object or a Uint8Array starts a child. For fork, only arrays, functions and regular expressions are rejected among object values.
• rejectsValidatedOption reads each member through the existing staticObjectProperty owner, and classifies its value only as far as syntax proves it. Unknown values stay.
• Both run beside the existing stdio, cwd/argv0, options-shape and callback filters in collectJavaScriptSemanticChildProcesses.
• Not included: killSignal, because Node's signal list differs by platform, and uid/gid, because Windows refuses any value with ENOTSUP.

Contribution scope: ordinary fix within existing boundaries; maintainer scope decision not applicable.

Contract and boundary impact

• Semantic owner and earliest changed stage: collectJavaScriptSemanticChildProcesses in javascriptSemanticChildProcesses.ts.

• Contribution scope fit and linked maintainer decision: not applicable.

• CLI and MCP/tool-catalog contract: none.

• Provider, bridge, target-format, or platform compatibility: none.

• Evidence, artifact, provenance, or reconstruction contract: fewer false spawn facts; undecided calls are unchanged.

• Target selection, authority, upstream behavior, and cleanup details: not applicable.

• Generated metadata, package, or installation impact: none.

• Read existing files or captured data.

Evidence and regression coverage

• Tests added: src/domain/javascript/javascriptSemanticAnalysis.child_process_command.test.ts, one row per rejected and accepted form above, across the four methods.
• Base reproduction: the new file on main source: 46 failed / 29 passed. With this change: 75 passed.
• Every row was first measured in Node 24.22.1 by calling the API with process.execPath -e 0 and recording the synchronous throw or the returned ChildProcess (killed at once).

Validation performed

Windows 11 Home 10.0.26200 x64, Node 24.22.1, base 9e24b36.

• npx vitest run src/domain/javascript/javascriptSemanticAnalysis.child_process_command.test.ts on main source: 46 failed / 29 passed; with this change: 75 passed.
• npx vitest run src/domain/javascript src/application/javascript: 217 files, 6457 passed / 7 skipped.
• Review follow-up (a3a7aa3): signed numeric and BigInt option values such as -1n and -1e400 are now priced; -0 stays an accepted timeout.
• npm run check:fast: passed (typecheck, lint)

Compatibility, safety, and release

• Breaking changes or migration steps: none.
• Real Hopper/Ghidra, browser, or OS coverage: Node 24.22.1 on Windows 11 for the measurements. The argument checks are in Node's platform-independent normalizeSpawnArguments; Linux was not measured.
• Package or release metadata impact: none.
• Security, privacy, process, or containment review: analysis only; nothing is executed.

Author readiness

Human owner: @Plastic-time

• I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
• I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
• I declare this PR ready for initial maintainer review.

Before merge

• This PR addresses a concrete problem or an agreed enhancement.
• Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
• The PR has one focused outcome and the title follows type(scope): outcome.
• Related issue is linked, or the reason for not linking one is stated above.
• Tests cover changed observable behavior and meaningful failure paths.
• Owning docs, contracts, and generated metadata are updated where needed.
• User-visible CLI/MCP changes include representative output.
• I checked the final diff for secrets, unrelated cleanup, and unsupported claims.