Inject a DB_NAME fallback for native WP-CLI commands

[youknowriad]

Proposed Changes

Full-site export builds a meta.json by running native WP-CLI commands (e.g. plugin list) that boot WordPress. On sites whose wp-config.php omits DB_NAME — common for pulled/imported sites, or sites only ever run under Playground (which supplies the DB connection at runtime) — the v3+ SQLite integration drop-in requires a non-empty DB_NAME, so those commands fail with “Error establishing a database connection.”

This injects the same fallback the Playground path already defines (define('DB_NAME','wordpress')) into the native WP-CLI invocation via --exec — but only when wp-config.php doesn't already define DB_NAME, so a real value is never redefined and sites that define it are untouched.

Testing Instructions

• npm test -- apps/cli/lib/tests/run-wp-cli-command.test.ts (4 tests).
• Full-export a site whose wp-config.php has no DB_NAME and confirm it no longer errors on the DB connection.

[youknowriad]

While working on something unrelated, my agent suggested this fix. I have to admin I have no idea if this is valid or not. cc @bcotrim @sejas just in case? Otherwise we can just close this PR.

[wpmobilebot]

📊 Performance Test Results

Comparing eadf276 vs trunk

app-size

Metric	trunk	eadf276	Diff	Change
App Size (Mac)	1316.76 MB	1316.76 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	eadf276	Diff	Change
load	1112 ms	1108 ms	4 ms	⚪ 0.0%

site-startup

Metric	trunk	eadf276	Diff	Change
siteCreation	6497 ms	6491 ms	6 ms	⚪ 0.0%
siteStartup	6554 ms	6569 ms	+15 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

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