Read bundled language packs directly from wp-files

[bcotrim]

Related issues

• Closes STU-1537 (completes the part deferred from Read bundled CLI dependencies directly from wp-files #3125)

How AI was used in this PR

Claude Code reconstructed the April context (#3125's deferred section, this PR's original debug instrumentation, and the language-pack copy races later documented in #3492), re-applied the bundle-read change cleanly on top of current trunk.

Proposed Changes

Language packs were the last site dependency still copied from the read-only CLI bundle into the writable ~/.studio/server-files/ cache on every CLI invocation. The copy was pure overhead: language packs are only ever read at site creation, to copy the matching locale's files into the new site's wp-content/languages/, and they only change when the app ships a new bundle.

This PR has site creation read language packs directly from the bundled wp-files/latest/languages/, and drops the per-invocation copy step — shaving the remaining recursive dir-walk (~1,400 files) off CLI startup.

Side benefits:

• The copy step needed lockfile serialization (CLI: Lock language pack setup #3492) because concurrent CLI invocations raced on the shared cache (transient ENOENT warnings). With no copy and no writable cache, that bug class is gone by construction.
• Site creation now skips the language-pack directory scans entirely for locales we don't bundle translations for (WP_LOCALES).
• The existing 04-cleanup-obsolete-server-files migration also removes the now-unused ~/.studio/server-files/language-packs/ (and its lockfile) on first run after upgrade.

On the April E2E failures that deferred this: they never reproduced locally — neither at the CLI level (3/3 ja-locale sites healthy, WPLANG=ja, wp-admin 200) nor with the packaged-app Playwright suites that failed in CI back then. The Playground worker-spawn stack has been rewritten since (#3602), and the failure was never root-caused, so CI on this PR is the deciding signal. If mac E2E reds again, this time it fails on a clean branch with inspectable artifacts.

Testing Instructions

1. npm run download-language-packs (plain npm install does not populate wp-files/latest/languages), then npm run cli:build.
2. Set a non-English locale (e.g. "locale": "ja" in ~/.studio/shared.json or via Studio Settings) and create a site.
3. Verify the site's wp-content/languages/ contains the locale's files (core + plugins/ + themes/), wp-admin loads in that language, and Settings → General shows the locale selected under Site Language.
4. Verify ~/.studio/server-files/language-packs/ is deleted on first CLI run after upgrade and is not recreated.
5. Covered by e2e localization.test.ts (locale site creation + WPLANG) and blueprints.test.ts (blueprint provisioning).

Verified locally on macOS arm64: typecheck, eslint, full unit suite (1963 tests), packaged-app e2e localization.test.ts 4/4 (twice) and blueprints.test.ts 6/6.

Pre-merge Checklist

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

[wpmobilebot]

📊 Performance Test Results

Comparing 1ae72b1 vs trunk

app-size

Metric	trunk	1ae72b1	Diff	Change
App Size (Mac)	1354.74 MB	1354.74 MB	0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	1ae72b1	Diff	Change
load	1666 ms	1667 ms	+1 ms	⚪ 0.0%

site-startup

Metric	trunk	1ae72b1	Diff	Change
siteCreation	9062 ms	8039 ms	1023 ms	🟢 -11.3%
siteStartup	4413 ms	3917 ms	496 ms	🟢 -11.2%

---

Results are median values from multiple test runs.

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

[epeicher]

Thanks @bcotrim, this is a great improvement! I have tested it, and I can verify that all steps work as expected. I can see that the languages file are stored there and they work as expected in the site. LGTM!

Language packs	Migration deletes the languages in server-files	WordPress site