Fix changing the WordPress version on a site that has never been started

[bcotrim]

Related issues

• N/A — found from a user's log, no issue filed yet.

How AI was used in this PR

Claude Code implemented the fix and wrote the tests. I reviewed the diff myself.

Proposed Changes

Changing the WordPress version now works on a site that has never been started.

A site created with --no-start has WordPress files on disk but no wp-config.php and no database — WordPress has not been installed yet. Any attempt to change its version failed with Failed to update WordPress version to <x>, because that path asks WP-CLI to boot a site that cannot boot. This affected the desktop app as well as the CLI: Site Settings sends the same command.

Nothing but the core files on disk decides such a site's version, so Studio now swaps those files in — exactly what site create --wp <version> does — and lets the WordPress installer run against them on the first start. Sites that have been started keep using wp core update as before.

Doing it this way also avoids a downgrade hazard: provisioning a database up front would install WordPress at the current version, and moving to an older version afterwards would leave the database at a newer schema than the code, which WordPress has no path back from.

WP-CLI failures now say what actually went wrong.

Several places threw a generic message and discarded WP-CLI's output entirely, which is why the original report showed stdout: '', stderr: '' and no reason at all. A failing export said only Database export failed. Errors now carry WP-CLI's own message, from both streams — which stream carries it depends on the runtime, and a message on the unread stream is a message nobody sees.

Trade-offs / known limits

• Exporting a site that has never been started still fails — there is no database to export — but it now says why instead of failing blankly. Making export work there is a separate question.
• Downgrading a never-started site copies the older files over the newer ones without pruning, so a few files from the newer version remain. This matches what site create already does on an existing WordPress directory; the site installs and serves normally (verified below).

Testing Instructions

Build the CLI first: npm run cli:build

CLI="node apps/cli/dist/cli/main.mjs"

$CLI site create --path ~/Studio/wp-version-test --no-start --skip-browser
$CLI site set --path ~/Studio/wp-version-test --wp 6.6.5

• Before this PR: Failed to update WordPress version to 6.6.5, exit code 1.
• After: ✔ WordPress version updated.

Confirm the files actually changed, then that the site installs at that version

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 52bbb9c vs trunk

app-size

Metric	trunk	52bbb9c	Diff	Change
App Size (Mac)	1362.04 MB	1362.04 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	52bbb9c	Diff	Change
load	1029 ms	1078 ms	+49 ms	⚪ 0.0%

site-startup

Metric	trunk	52bbb9c	Diff	Change
siteCreation	7014 ms	7002 ms	12 ms	⚪ 0.0%
siteStartup	2355 ms	2357 ms	+2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)