Add an experimental Kandelo-backed Playground runtime

## Goal

Run WP Codebox's existing WordPress runtime, recipe, Playwright, and evidence contracts against WordPress Playground backed by Kandelo, while preserving Playground as the WordPress compatibility boundary and Kandelo as the runtime owner.

This should provide a concrete downstream proving ground for Kandelo and a compatibility path toward Playground eventually selecting Kandelo by default.

## Existing upstream work

- Kandelo roadmap and Playground integration direction: https://github.com/Automattic/kandelo/issues/382
- Playground CLI proof of concept: https://github.com/WordPress/wordpress-playground/pull/3634
- Playground Web proof of concept: https://github.com/WordPress/wordpress-playground/pull/3635
- WP Codebox runtime backend factory seam: https://github.com/Automattic/wp-codebox/issues/974

The Playground proof-of-concept branches already run nginx and PHP-FPM on Kandelo and preserve substantial portions of the Playground CLI, client, worker-endpoint, and Blueprint interfaces. They remain experimental and document current capability gaps.

## Ownership boundaries

- **WP Codebox** owns runtime selection, lifecycle, mounts, snapshots, recipes, host-side Playwright automation, browser evidence, policy, artifacts, replay, and compatibility reporting.
- **WordPress Playground** owns the WordPress-facing runtime API, Blueprint behavior, client/worker endpoint compatibility, and engine selection integration.
- **Kandelo** owns the POSIX kernel, nginx/PHP-FPM runtime, VFS, process/network behavior, binaries, and runtime defects.
- **Homeboy and Homeboy Extensions** consume WP Codebox's generic contracts unchanged. They should not acquire Kandelo-specific paths, environment names, or behavior.

Downstream recipes should remain engine-neutral. Kandelo or Playground deficiencies discovered by the matrix should be linked upstream rather than hidden with WP Codebox-specific compensating behavior.

## Proposed shape

Start with an explicit experimental backend/provider so capability differences remain honest, for example:

```text
wordpress-playground
wordpress-playground-kandelo
```

Once Playground exposes a stable engine selector with compatible behavior, converge toward a single Playground backend with explicit engine configuration:

```json
{
"backend": "wordpress-playground",
"runtime": {
"engine": "kandelo"
}
}
```

When Playground makes Kandelo the default and compatibility is proven, callers should no longer need to select an engine.

Playwright remains host-side in every topology:

```text
WP Codebox
-> host Playwright / Chromium
-> WordPress Playground contract
-> PHP.wasm or Kandelo
-> WordPress
```

## Compatibility matrix

Run the same WP Codebox recipes and evidence assertions against PHP.wasm and Kandelo. Record supported, unsupported, divergent, and failed behavior for:

- runtime creation, readiness, teardown, cancellation, and resource bounds;
- WordPress and PHP version selection;
- host mounts, readonly mounts, staged files, and generated artifacts;
- Blueprint steps used by WP Codebox, including `runPHP`, `writeFile`, `installPlugin`, activation, options, and login;
- WordPress HTTP, PHP, WP-CLI, PHPUnit, and ability execution;
- checkpoints, snapshots, restore, and replayable bundles;
- browser preview routing, authentication, cookies, mapped domains, and multisite;
- Playwright browser probes, actions, scenarios, screenshots, traces, console/errors, network, WebSockets, visual comparison, and adaptive exploration;
- SQLite and declared external-service/database behavior;
- runtime overlays, PHP extensions, and dependency projection;
- deterministic artifact schemas, provenance, diagnostics, and cleanup evidence.

Compatibility proof must cover existing response and artifact schemas, observability identifiers, timing/retry behavior, mixed engine selection, and failure classification, not only successful new workflows.

## Delivery slices

1. **Provider spike:** package or load the Playground Kandelo POC behind an experimental WP Codebox backend provider without changing existing default behavior.
2. **Contract harness:** run a bounded representative WP Codebox recipe suite against both engines and emit a machine-readable compatibility report.
3. **Capability closure:** file and link owning-layer Kandelo or Playground issues for each unsupported or divergent contract; keep unsupported results explicit.
4. **Evidence parity:** prove existing host Playwright and artifact collection are engine-neutral.
5. **Promotion gate:** define the subset required for supported experimental use, then the complete parity gate required before default selection or backend convergence.

## Acceptance criteria

- WP Codebox can select Kandelo explicitly without changing the existing PHP.wasm default.
- At least one real mounted WordPress plugin runs through the same recipe on both engines.
- The same host Playwright command captures browser assertions, screenshot, console/error, network, and trace evidence from both engines.
- A machine-readable compatibility report identifies every exercised contract dimension and links known gaps to owning upstream trackers.
- Existing WP Codebox recipe, runtime, response, artifact, provenance, retry, and cleanup contracts remain compatible.
- Unsupported Kandelo capabilities fail explicitly with stable diagnostics rather than silently falling back to PHP.wasm.
- Kandelo selection does not introduce Kandelo-specific concepts into Homeboy or Homeboy Extensions.
- A documented promotion gate defines when Kandelo can be treated as equivalent and when the explicit engine distinction can be removed.

## Non-goals

- Running Chromium or Playwright inside Kandelo.
- Reimplementing Playground's Kandelo adapter in WP Codebox.
- Forking WP Codebox browser evidence for Kandelo-specific behavior.
- Making Kandelo the default before Playground integration and compatibility evidence support that decision.

## AI assistance

OpenAI GPT-5.6 Sol via OpenCode was used to inspect the current Kandelo, Playground, and WP Codebox runtime boundaries; identify the canonical ownership model; and draft this tracker. Chris Huber reviewed and remains responsible for the issue.

Empieza leyendo la interfaz factory del backend de runtime de WP Codebox en issue #974 y los contratos existentes de runtime, recipe y evidence. Ejecuta la recipe representativa y la suite de Playwright del lado del host contra los proveedores basados en PHP.wasm y Kandelo, y después compara el informe de compatibilidad legible por máquina. Se considera terminado cuando la selección explícita del engine funciona sin cambiar el valor predeterminado, las capacidades no compatibles fallan claramente y los contratos requeridos de evidence y artifact siguen siendo compatibles.

Escrito por el modelo de indexación a partir del texto del issue.