Windows: the Gutenberg build opens console windows, and closing one breaks the build

Description

On Windows, the full build of a Gutenberg site opens one or more black console windows (they look like cmd.exe) while it runs. A Core build does not. Closing one of them kills part of the build's process tree: npm reports Build failed: Command failed: wp-build and exits 1, while wp-build itself survives as an orphan and keeps writing to the app's terminal (see #498).

Where it likely comes from. The app spawns the runner with windowsHide: true and no console; npm's own cmd.exe /d /s /c node ./build.mjs inherits that. Gutenberg's tools/build-scripts/build.mjs then spawns tsc --build and wp-build through cross-spawn, which on Windows wraps .cmd bin stubs in another cmd.exe; the app's spawn patch does the same for any .cmd it resolves (shell: true, no windowsHide). One of those links gets a fresh visible console. Core's grunt never spawns a .cmd below npm, which is why it has never shown one. The exact link needs a Windows machine to pin down: run the build with WP_DEV_ENV_HTTP_LOG unset and Process Explorer open, and see which process owns the new console.

Step-by-step reproduction instructions

1. Windows, Gutenberg site past the install step.
2. Run full build.

Expected: no windows. Actual: black console windows appear during the transpile/bundle phases.

Operating system

Windows 11 (UTM VM, arm64 host running x64 Windows). Not seen on macOS.

App version

Trunk at 4c53900 (v1.2.0-beta.1 pass).

Start with Gutenberg's tools/build-scripts/build.mjs and the app's spawn patch, then run the full build on Windows with WP_DEV_ENV_HTTP_LOG unset and Process Explorer open. Trace which spawned process owns the visible console. Done means the full Gutenberg build opens no console windows and remains intact when they are closed.