Avoid redundant WordPress bootstraps during Playground install/start

[adamziel]

Problem

Playground CLI startup was doing redundant WordPress boot work around install/start, and Studio also needs a trustworthy signal for whether boot already applied requested admin credentials. Recent profiling also showed two distinct remaining costs:

• the normal WordPress installer request is still the largest single cost
• eager multi-worker boot can hide the savings from install-option cleanup

Implementation

• Adds typed WordPressInstallOptions and threads them through runCLI, the Blueprint v1 worker payload, and bootWordPress.
• Uses siteTitle as the canonical install option name, while accepting weblogTitle plus wordpressInstallOptions / deprecated studioInstallOptions aliases at the CLI integration boundary for compatibility.
• Passes site/admin values to the normal /wp-admin/install.php?step=2 installer POST. This intentionally keeps the standard installer request path and does not shortcut to wp_install().
• Collapses post-install installed-site validation, default permalink setup, DB connection checking, and optional admin credential application into one php.run() after the installer request.
• Exposes wordpressBootResult.adminCredentialsApplied on the actual runCLI() server return value, in addition to lower-level boot metadata, so Studio can skip a redundant fallback mutation when boot already handled credentials.
• Starts only the primary worker before WordPress install, then starts secondary server workers after install. Plain server startup backgrounds secondary workers; server startup with Blueprint/phpMyAdmin post-boot steps waits for secondary workers first so those steps run against the final worker pool. Non-server commands also still wait for all workers before continuing.
• Adds lightweight debug timing spans for worker request-handler boot, bootWordPress, installer request, finalization, Blueprint v1 steps, and secondary worker boot.
• Keeps the old separate DB connection assertion path for failure diagnosis/error preservation.

Compatibility / behavior

• Defaults are unchanged when install options are omitted.
• Existing installed sites are not reinstalled in install-from-existing-files-if-needed mode.
• Existing sites can apply provided admin credentials during the existing boot finalization run; adminCredentialsApplied is only true when requested credential state verifies afterward.
• This does not introduce DB preseeding, shared WordPress core, direct wp_install(), or Defender/ReFS-specific behavior.

Security

adminPassword is not included in the boot result or debug/perf metadata. It is only sent to the installer/finalization paths needed to set credentials.

Perf notes

These are local Studio profiling measurements from the investigation that motivated this PR, not CI benchmarks, and I have not remeasured the exact latest commit after adding deferred secondary-worker boot:

• Fresh child startup improved from about 21.8s on trunk to about 13.2-13.9s with this patch class, depending on run shape.
• The removed post-install admin/title fallback path accounts for about 1.9s of saved startup work in the measured run.
• With STUDIO_WORKERS=1, child startup measured about 9.8s instead of 13.9s with six workers, which is why this PR now defers secondary server workers until after the primary install path.

This is still a cleanup/small-to-medium install-path win rather than a full step-change: the standard /wp-admin/install.php?step=2 request remains the largest floor, measuring roughly 5.7-6.8s by itself in those profiling runs. A bigger improvement would need a separate, riskier fast-install path such as guarded direct wp_install() or DB seeding.

Tests

• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec nx run playground-cli:typecheck
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec -- vitest run tests/run-cli.spec.ts --config packages/playground/cli/vite.config.ts -t "multi-worker install credentials"
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec -- vitest run tests/run-cli.spec.ts --config packages/playground/cli/vite.config.ts -t "blueprint after secondary"
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec vitest run src/test/install-options.spec.ts -- --config packages/playground/wordpress/vite.config.ts
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec nx run playground-wordpress:lint
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec nx run playground-cli:lint
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec nx run playground-wordpress:build:bundle
• PATH=/usr/local/opt/node@22/bin:/opt/homebrew/opt/node@22/bin:$PATH npm exec nx run playground-cli:build:bundle

Also attempted the broader playground-wordpress:test:vite path earlier; the new install-options tests passed, but the existing version-detect.spec.ts trunk runtime case still timed out at 30s.