Upgrade Playground runtime for complete external-extension ABI

[chubes4]

Problem

WP Codebox pins WordPress Playground 3.1.46. A PHP 8.4 JSPI extension produced through the supported @php-wasm/compile-extension workflow can import public PHP symbols that this main module does not export. Runtime boot then fails before command dispatch with:

TypeError: resolved is not a function
    cause: Comlink method call failed

Static WebAssembly.Module.imports() comparison against @php-wasm/node-8-4@3.1.46 confirms missing function exports including:

explicit_bzero
convert_to_null
_emalloc_448
php_password_algo_find
php_password_algo_register
sscanf

WordPress Playground fixed this contract in issue #4107 and merged PR #4108. The current npm release is 3.1.52; WP Codebox still pins 3.1.46.

Expected

• Converge all Playground/PHP.wasm packages on a release containing the complete external-extension ABI.
• Add deterministic coverage comparing a fixture extension's function imports with the selected main-module exports so dependency drift fails before runtime execution.
• Verify a JSPI external extension reaches PHP command dispatch instead of surfacing the unnamed dynamic-linker TypeError.

Evidence

A retained WP Codebox recipe run proved backend package import, runtime creation, managed MariaDB readiness, and extension-manifest resolution. The failure occurred when PHP.wasm first booted; the workflow command was never recorded. The package provenance was WP Codebox 0.26.3, Playground CLI/PHP.wasm 3.1.46, PHP 8.4, JSPI.

AI assistance

OpenAI GPT-5.6 Sol via OpenCode traced the runtime artifact to PHP.wasm's dynamic linker, compared side-module imports with main-module exports, found the merged upstream ABI repair, and drafted this tracker with Chris Huber.