runCLI() swallows errors via process.exit(1) instead of re-throwing

[adamziel]

Problem

runCLI() in packages/playground/cli/src/run-cli.ts wraps the entire server setup in a .catch() that calls process.exit(1) after printing the error:

// Bundled output in run-cli-B9kBDU12.js, line 1638-1640 (v3.1.20):
}).catch((c) => {
    i.printError(Se(c)), process.exit(1);
});

This means callers of runCLI() can never catch or handle errors from the server setup — the process just dies.

Impact

When embedding Playground CLI as a library (e.g. WordPress Studio spawns it as a daemon child process), non-fatal errors during startup (such as a background worker exit race condition) kill the entire process. The caller has no opportunity to inspect the error, retry, or report it — the error is printed to stdout via printError() and then process.exit(1) terminates immediately.

Reproduction

import { runCLI } from '@wp-playground/cli';

try {
    // If runCLI's internal setup promise rejects (e.g. a transient
    // worker error), this process.exit(1) fires instead of the catch
    // block below.
    const server = await runCLI({
        command: 'server',
        path: '/tmp/test-site',
        port: 9400,
    });
} catch (error) {
    // Never reached — process is already dead.
    console.error('Could have handled this:', error);
}

Suggested fix

Re-throw the error instead of calling process.exit(1), so callers can handle it. The process.exit(1) behavior could be kept as a default for the standalone CLI entry point, but runCLI() as a library API should propagate errors normally.

Source location

packages/playground/cli/src/run-cli.ts — the .catch() at the end of the server setup promise chain.

Version: @wp-playground/cli 3.1.20