Fix readonly Playground mount isolation

[chubes4]

Closes #1797

Summary

• Snapshot every readonly MountSpec into a runtime-private temporary directory before passing it to Playground's writable Node filesystem mount handler.
• Preserve direct host-backed behavior for explicit readwrite mounts.
• Bind staging cleanup to both startup failure and runtime disposal.
• Cover the mount boundary with both a fast CLI adapter test and a real recipe-run Playground integration test.

How to test

1. Run npm run build.
2. Run npm run test:playground-readonly-mounts-integration. It invokes packages/cli/dist/index.js recipe-run, writes binary readonly and readwrite mounts from wordpress.run-php, verifies the readonly host SHA-256 is unchanged, verifies the readwrite host bytes changed, and verifies readonly staging cleanup. It skips only when structured recipe output proves Playground's WordPress archive or release metadata acquisition failed during runtime_startup because the external source was unavailable; all runtime, workflow, mount, and assertion failures fail the test.
3. Run npm run test:playground-readonly-mounts. It retains fast coverage for CLI mount substitution and runtime-disposal cleanup.
4. Run npm exec tsx -- tests/playground-cli-runner-bootstrap-ini.test.ts.
5. Run npm exec tsx -- tests/programmatic-playground-runner.test.ts.

Compatibility

readwrite mounts keep their existing host-write semantics. readonly mounts now begin from a private snapshot: writes inside Playground remain private to that runtime and are no longer reflected in the source checkout, which enforces the documented mode contract.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode / openai/gpt-5.6-terra
• Used for: Investigated the runner boundary, implemented readonly staging and lifecycle cleanup, and added focused integration coverage with Chris's requested acceptance criteria.