Add a native PHP runtime backend for representative performance testing

[chubes4]

Problem

WP Codebox currently executes contained WordPress browser workflows through the Playground PHP-WASM backend. That backend is excellent for portable, isolated functional proofs, but its execution characteristics can dominate application latency and prevent production-representative performance conclusions.

A controlled local benchmark using identical three-command no-op recipes measured:

Runtime	First command, including startup	Warm command 1	Warm command 2
Large full-stack WordPress application on Playground	39.0 s	17.8 s	14.0 s
Stock WordPress on Playground	34.8 s	0.7 s	0.5 s

Application bootstrap checkpoints attributed roughly 12-16 seconds of each warm request to wp-settings.php, with approximately 235 MB peak memory. The current backend also serializes upstream requests through one PHP instance to protect mutable runtime state. These properties are deterministic and safe, but they differ materially from native PHP with persistent OPcache, concurrent request workers, and a conventional database.

This means Codebox can answer functional and matched-cohort questions, but it cannot currently support claims about production-representative absolute latency for large WordPress applications.

Desired capability

Add an optional native PHP runtime backend behind the existing Codebox runtime-backend contract. The implementation may use a local container or another contained native process model, but runtime-core and recipe callers should remain implementation-neutral.

The backend should provide:

• Native PHP execution with explicit PHP version provenance.
• Persistent OPcache configuration and evidence.
• Multiple request workers or equivalent realistic HTTP concurrency.
• A disposable conventional database service, such as MariaDB, through existing managed-service contracts.
• Existing Codebox recipe commands, browser routing, network policy, artifact capture, lifecycle, and safety boundaries.
• Deterministic teardown and no access to ambient host credentials or production state.
• Machine-readable backend and environment provenance so results from native and Playground backends cannot be confused.

Acceptance criteria

• The same backend-neutral WordPress recipe can select Playground or native execution without changing workflow commands.
• A browser workflow can boot WordPress, execute authenticated fixture requests, and capture existing browser/network evidence on the native backend.
• Parallel browser requests are served with a documented concurrency model.
• OPcache status/configuration is captured in reviewer-safe evidence.
• A baseline benchmark reports cold startup, warm no-op PHP requests, and a dynamic WordPress request for both backends.
• Native-backend artifacts clearly identify that timings are locally representative evidence, not production RUM.
• Existing Playground behavior remains unchanged.

Non-goals

• Replacing Playground as the default portable backend.
• Adding application-specific paths, constants, fixtures, or package assumptions to runtime-core.
• Claiming local native measurements are production RUM.

Immediate downstream value

A downstream large-application editor benchmark needs matched feature-on/feature-off latency evidence. Playground can retain the functional proof while this backend provides a credible performance lane using the same recipes and artifact contracts.

AI assistance

OpenAI gpt-5.6-sol via OpenCode assisted with repository inspection, controlled benchmark execution, architecture analysis, and drafting this issue. Chris Huber directed the investigation and tracking decision.