fix(playground): propagate phpEnv into PHP.run and request workers

[chubes4]

Summary

External-database connector secrets were passed to Playground CLI as phpEnv (mapped to Emscripten ENV) but never applied to the PHP APIs that actually populate getenv().

PHP-WASM applies environment per run via PHP.run({ env }) → wasm_add_ENV_entry. Isolated executions with processIdentity go through request workers and putenv() only the payload environment. Both paths dropped phpEnv:

• shouldUseProgrammaticPlaygroundRunner forces the CLI/backendPackage path for databaseSetup: "external" and whenever a cliModule is provided.
• secretEnvPhp strips connector secrets from generated command PHP (so they are not serialized).
• Auto-prepend also omits secrets.
• playground.run() was called with { code } only.
• Request-worker payloads used spec.environment only.

WordPress then defined DB_PASSWORD from getenv('DB_PASSWORD') (empty) and mysqli failed with access denied.

This change injects runtimePhpEnvironment() into every playground.run() and into request-worker payloads. Secrets stay out of PHP source and auto-prepend files.

The PHP 8.4 overlay remains the deliberate 3.1.53 floor (ABI exports from WordPress/wordpress-playground#4108). The Playground driver stays on 3.1.46 so the 8.3 overlay and CLI patch still dedupe; #4146 is still open, so overlay carry is not dropped.

Tests

• Existing CLI mocks now read runOptions.env instead of runCLI.phpEnv (that previous mock hid the hole).
• New tests/playground-cli-php-env-propagation.test.ts covers isolated request-worker payload injection.

npm run check passed.

AI assistance: GPT-6 Astra via OpenCode diagnosed the blocker chain; Grok 4.6 via opencode run implemented the fix and ran the suites.