[CLI] Allow API consumers to rely upon option validation and default values

[brandonpayton]

Motivation for the change, related issues

Today, API consumers like WordPress Studio use Playground CLI's runCLI() method directly which skips argument validation and default values.

Example here:
Automattic/studio#2058

Currently, I'm manually getting the CPU core count and creating n - 1 workers. I believe Playground is supposed to do that detection itself, but when I just pass experimentalMultiWorker, it runs with true as the number of workers and doesn't actually create multiple workers. Happy to drop the detection of core count in Studio if that can be done in Playground CLI itself, though.

This PR adjusts the API so consumers can rely upon CLI argument validation and default values.

Implementation details

This PR adjusts the signature of parseOptionsAndRunCLI() to accept a string array of command line arguments so Studio can rely upon Playground CLI defaults for options like --experimental-multi-worker or --experimental-unsafe-ide-integration rather than having to provide their own defaults.

Pros

• Enjoy Playground CLI default values
• Validate all argument values
  • This includes values that would not violate the type system. For example, passing experimentalMultiWorker: -1 to runCLI() is allowed by TypeScript because the value is a number, but it is an invalid number that would be caught by command line argument validation.
• This allows us to write tests for how Playground CLI responds to invalid command line arguments.

Cons

• Arguments are all strings and are not strongly typed. The risk from this can be mitigated by using a typed object to build the args and rendering an array of strings just before passing them to Playground CLI.

cc @griffbrad @wojtekn

Testing Instructions (or ideally a Blueprint)

• CI

[brandonpayton]

There is a failing test for Playground CLI:

The notable bit is:

2025-11-11T23:02:45.8880538Z - StringMatching /^Resolved WordPress release URL: https://downloads.w.org/release/wordpress-\d+.\d+.\d+.zip$/,
2025-11-11T23:02:45.8881210Z + "Resolved WordPress release URL: https://downloads.wordpress.org/release/wordpress-6.9-RC1.zip",

Playground CLI is downloading the WP 6.9 release candidate. This makes sense because we query https://api.wordpress.org/core/version-check/1.7/?channel=beta for the latest release. The beta channel includes the RC. If we remove the beta channel query arg, we get the latest release.

It looks like we started using that URL as part of this PR:

• Blueprints: Resolve the latest WordPress version from the API instead of assuming it's the same as the last minified build #2027

@adamziel is it intended that Playground CLI uses the beta/RC by default if one exists?

[brandonpayton]

Note: If I change the WP latest version query URL to https://api.wordpress.org/core/version-check/1.7/, the tests pass locally.

[wojtekn]

As a user, I would expect getting the latest stable, and not beta, when I use the "latest" option.

[zaerl]

As a user, I would expect getting the latest stable, and not beta, when I use the "latest" option.

About to be fixed on #2889

[brandonpayton]

This is also simple and low-risk. The tests pass. Let's merge.