fix(cli): verify Chrome can execute during preflight

[vanceingalls]

What

Chrome preflight now runs the selected binary with --version before reporting it usable. Refs PRINFRA-344.

Why

Cached and explicitly configured binaries could exist but fail to execute, while doctor/render preflight reported Chrome OK. This hid architecture, permission, and startup-crash failures.

How

Use a shell-free, five-second bounded probe with captured output. Failed probes produce a blocking outcome containing the exit code, signal, or OS error and working-browser/reinstall guidance. Existing Linux missing-library diagnostics retain precedence. This verifies executability, not full rendering compatibility or the initiating macOS crash cause.

Test plan

• Unit tests added/updated: 41 preflight/doctor tests passed; focused preflight suite rerun after refactoring.
• Manual test: actual temporary executables returning 133 and 0 produced failing and successful preflight results respectively.
• Documentation updated (not applicable).

CLI typecheck, changed-file oxlint/oxfmt, diff check and fallow gate passed.

[jrusso1020]

Read the full preflight.ts and its test file at head, plus the render path that consumes the outcome.

Strengths

• Both call sites that satisfy the new contract are covered. chromeLaunchOutcome replaces chromeSharedLibOutcome at the explicit-browserPath branch (packages/cli/src/browser/preflight.ts:232) and the discovery branch (:262), and the new test exercises both by looping for (const browserPath of [undefined, process.execPath]). Auditing every site rather than the one that produced the report is the step most PRs of this shape skip.
• Precedence ordering is right, and the body's claim about it is verifiable. chromeLaunchOutcome calls chromeSharedLibOutcome first and returns early when it fails, so a Linux box with missing libraries still gets the specific per-distro install command instead of a generic "Chrome cannot start". "Existing Linux missing-library diagnostics retain precedence" — confirmed in code, not just asserted.
• The probe is stricter than the file's own precedent. It reuses the same timeout: 5000 as the existing FFmpeg check (:64-68) but adds killSignal: "SIGKILL", a bounded maxBuffer, and explicit stdio. Consistent with the surrounding code while being harder to hang.
• The happy path is retained rather than assumed: the Chrome-ok tests at :221 and :237 now run through the new probe, so success isn't only covered by the new failure cases.
• The blocking claim is real — packages/cli/src/commands/render.ts:823-829 calls failCommand() on any !outcome.ok, so an unusable binary now stops the render before any work is done. That is the point of the change, and result.browser is correctly left undefined because it is only populated when chrome.ok (preflight.ts:327-334).

Notes, not blockers

• This is now a hard gate on every hyperframes render. The 5s bound matches the FFmpeg precedent so it is internally consistent, but the new failure mode is "a working install refuses to render" if a cold first spawn exceeds it — Windows AV scanning a freshly downloaded binary, a network-mounted executable, or a heavily loaded CI runner. The common case is ~100ms, so if that ever shows up in the field the cheap mitigation is a single retry rather than a longer timeout.
• chromeLaunchFailureDetails returns "" for a non-object throw, leaving the detail as Failed to run "<path>" --version. with no cause. That reads fine; noting only that the empty-string path is deliberate.

Head reviewed: c2702e4c76d9c55f12a44641efd14e66c3749702

Verdict: APPROVE
Reasoning: Narrow, well-scoped fix that closes a real gap between "binary exists" and "binary runs", both call sites are audited and tested, and it follows the existing preflight conventions rather than inventing new ones.

— Rames Jusso