Scale Playground materialization for large host directory mounts

[chubes4]

Problem

materializePlaygroundStagedInputs() does not scale to large host directory mounts. A WPCOM readonly tree with roughly 257,000 entries completes host-side readonly staging in 31.7 seconds, then times out after 1,500 seconds in input.materialize before any recipe command runs.

The materializer calls playground.writeFile() serially for every UTF-8 file and adds a verification call every 100 files. This makes runtime startup proportional to hundreds of thousands of cross-boundary calls rather than bounded batches.

Evidence

Runtime facts from an isolated parity run:

• runtime.workers: 1
• readonly host staging: completed in 31,681ms
• active operation at timeout: input.materialize
• timeout: 1,500,000ms
• commands executed: 0
• managed MariaDB reached ready state and was released cleanly

The relevant loop is in packages/runtime-playground/src/mount-materialization.ts: each text file awaits server.playground.writeFile(target, text) independently. Binary files already use the PHP batch path.

Reproduction

1. Generate a directory tree containing at least 250,000 small UTF-8 files.
2. Add it as a readonly directory mount to a minimal Playground recipe.
3. Run wp-codebox recipe-run --recipe recipe.json --artifacts artifacts --timeout 1500000ms --json.
4. Observe readonly staging complete, followed by timeout in input.materialize with no workflow commands executed.

Expected

Large host trees should be transferred through a bounded bulk/streaming primitive with deterministic progress and verification, avoiding one Playground call per file. Existing binary fidelity, readonly isolation, symlink policy, nested mounts, diagnostics, and timeout behavior must remain intact.

[chubes4]

Parity follow-up: bounded PHP batching alone is insufficient. Retained runs with 100-file and 1,000-file batches both timed out after 1,500,000ms in input.materialize, with zero workflow commands executed. Readonly host staging completed in 31.7s–54.4s, runtime.workers was 1, and the active PHP 8.4 Wasm was independently verified at fixed ABI SHA-256 79297f602d4c6462465b72c8beda728683e856fa224bb0290a25b8587ebb2805. The next repair should use one bounded archive/stream transfer and in-VFS extraction, with progress and integrity evidence, rather than tuning per-file batch counts.

[chubes4]

Further root-cause evidence (retained runs v73-v75): removing redundant host-to-VFS rewrites is correct and all direct-mount/readwrite/readonly integration tests pass, but the real parity wrapper still stalls inside startPlaygroundCliServer() before preview:connecting-client. Direct runCLI() boots the same 257k tree in 336-483ms with workers=1, fixed ABI SHA 79297f..., JSPI flags, sodium manifest, exact canonical mounts, bootstrap mounts, empty Blueprint, fixed nonzero port, and captured stdout/stderr. v73 separately exposed /dev/shm quota exhaustion from six retained 5.6GB snapshots; v74/v75 reused an existing snapshot and still timed out. In-process HTTP, worker-thread HTTP, child-process HTTP, and resolved native version cache paths were tested; the exact WP Codebox startup function still hangs while direct runCLI() succeeds. No new custom archive is created on the resolved-version path. Branch commits remain local/unpushed pending a deterministic explanation of the wrapper-only difference.