wp_mysql_parser: conditional WASM loader for PHP 8.4 (draft, stacked)

[adamziel]

Stacked on #3547. Third PR in the chain exploring extension loading.

What

Wires the MySQL lexer/parser extension from WordPress/sqlite-database-integration#381 into Playground as a side module. Gated to PHP 8.4 in this run while we have no broader build matrix to test against — other versions throw a clear error at boot.

How to use

The .so isn't bundled (no published artifact yet). Build the extension from PR #381 and pass the path:

```
npx @wp-playground/cli server --php=8.4
--wp-mysql-parser-so=/path/to/wp_mysql_parser.so
```

Implementation

• New `with-wp-mysql-parser.ts` wrapper, same shape as `with-xdebug` / `with-intl` after the refactor in Refactor xdebug + intl to use loadPHPExtension helper (draft, stacked) #3547. Calls `installPHPExtensionFilesSync` in `onRuntimeInitialized`.
• Plumbed through Blueprints v1: `run-cli.ts` → `blueprints-v1-handler.ts` → `worker-thread-v1.ts` → `loadNodeRuntime` → `withWpMysqlParser`.
• The version gate is in the wrapper itself (`SUPPORTED_VERSIONS = ['8.4']`) so widening is a one-line change.

Out of scope

• Blueprints v2 plumbing
• Browser-side loader (this wrapper is node-only — it `fs.readFileSync`s the .so; a web counterpart would `fetch` it)
• Bundling a prebuilt artifact into a per-version package like `@php-wasm/wp-mysql-parser-8-4` (mirroring how Xdebug ships)
• A blueprint-step variant — the generic `loadPHPExtension` step from Blueprints: loadPHPExtension step (draft) #3545 already covers the URL-fetch case

Test plan

• Build wp_mysql_parser.so against PHP 8.4 JSPI, run `server --php=8.4 --wp-mysql-parser-so=...`, verify `extension_loaded('wp_mysql_parser')` is true
• Pass --php=8.3 with --wp-mysql-parser-so and confirm the clear error message
• Confirm Xdebug + intl still work (they share installPHPExtensionFilesSync via Refactor xdebug + intl to use loadPHPExtension helper (draft, stacked) #3547)