fix(engine): hide ffmpeg console windows on Windows

[miguel-heygen]

What

Pass windowsHide: true at every production ffmpeg/ffprobe spawn site.

Closes #3379.

Why

ffmpeg and ffprobe are console-subsystem binaries, and Node's child_process.spawn
defaults windowsHide to false. Every spawn therefore opens a visible console window on
Windows. A render shells out dozens of times across parallel workers, so the reporter saw a
burst of windows appear and disappear across their desktop, ~11 at once with 6 capture
workers.

Cosmetic, but it is the first impression of a render on Windows.

How

The report named two call sites. Seven production sites share the cause, so all seven
are fixed rather than the two mentioned:

file	site
engine/src/utils/runFfmpeg.ts	the shared runner, used across the pipeline
engine/src/utils/gpuEncoder.ts	-encoders probe
engine/src/utils/gpuEncoder.ts	per-encoder probe
engine/src/utils/ffprobe.ts	metadata probe
engine/src/services/streamingEncoder.ts	streaming encode
producer/src/services/audioExtractor.ts	audio extraction
producer/src/services/distributed/shared.ts	ffmpeg -version check

windowsHide is a no-op on macOS and Linux, so it is applied unconditionally.

Left alone deliberately: parity-harness.ts, regression-harness.ts and
mediaTypeTestFixtures.ts all spawn ffmpeg too, but they are dev-only tooling that never
runs on a user's desktop. Changing them would widen the diff without changing the reported
behaviour.

Test plan

• Unit tests added/updated
• Manual testing performed
• Documentation updated (if applicable)

Regression test

runFfmpeg.windowsHide.test.ts mocks child_process and asserts on the options object
actually handed to spawn:

const options = spawnMock.mock.calls[0]?.[2] as { windowsHide?: boolean } | undefined;
expect(options?.windowsHide).toBe(true);

Asserted on behaviour rather than on source text, so a future call site that drops the flag
is caught by what it does, not by how it is written.

Verified it fails without the fix:

$ # windowsHide removed from runFfmpeg
FAIL  runFfmpeg.windowsHide.test.ts > hides the console window so Windows renders do not flash terminals
$ # restored
Tests  1 passed (1)

Other checks

• vitest packages/engine/src/utils/ — 651 passed, 20 files
• oxlint + oxfmt on all 7 touched files — clean
• Pre-commit hooks (fallow, typecheck, commitlint) — green

Before / after

I do not have a Windows machine, so I cannot capture the desktop screenshots this one
really wants. The observable change is at the spawn boundary, and that is what the test
pins:

before   spawn(getFfmpegBinary(), args)                          -> console window per call
after    spawn(getFfmpegBinary(), args, { windowsHide: true })   -> no window

The reporter's repro repo is linked in #3379 and is the right way to confirm the desktop
behaviour on a real Windows box before merge.

[miguel-heygen]

Scope note, from a second Windows report that landed after this PR was opened.

This PR closes the ffmpeg/ffprobe half. It does not close the browser half, and I want
that on the record so the PR is not read as fixing the whole reported symptom.

one Windows Terminal window can open per cached chrome-headless-shell worker on Windows 11
... visible console windows use the cached HyperFrames chrome-headless-shell path as their
title. OUTCOME: render succeeds but interrupts the desktop.

Those windows come from Puppeteer's own launcher, not from any spawn in this repo.
@puppeteer/browsers@3.0.6 spawns the browser as:

this.#browserProcess = childProcess.spawn(this.#executablePath, this.#args, {
  detached: opts.detached,
  env,
  stdio,
});

No windowsHide, and the supported opts are only pipe, dumpio, handleSIGINT,
handleSIGTERM, handleSIGHUP, detached and env — there is no pass-through we could
set from ppt.launch(). Our launch sites in browserManager.ts and hdrCapture.ts have
nowhere to put the flag.

So the remaining half needs one of:

1. an upstream change to @puppeteer/browsers to set windowsHide: true (or accept it as
   an option), or
2. documenting the workaround the reporter found — point HYPERFRAMES_BROWSER_PATH at an
   installed GUI Chrome, which is not a console-subsystem binary.

Worth deciding which before closing the original issue, since a Windows user with this PR
merged will still see browser windows and reasonably think nothing changed.