Add pure-PHP SQLite engine compatibility for WordPress and WooCommerce

[adamziel]

What it does

Adds a pure-PHP SQLite-compatible engine path so the SQLite integration can run without pdo_sqlite.

This PR also expands compatibility for WordPress and WooCommerce-style SQL:

• Wires WP_PHP_Engine_PDO into the MySQL-on-SQLite driver and install/bootstrap paths.
• Adds file-backed persistence, transaction snapshots, write locking, PDO fetch compatibility, and virtual SQLite metadata tables.
• Covers more MySQL-on-SQLite patterns: multi-query execution, joined updates that read from information_schema, views, triggers, routines/events metadata, logical database metadata, CTAS, defaults, ALTER TABLE cases, and legacy SQLite fallbacks.
• Adds pure-PHP engine test variants for the driver, PDO API, metadata, query, information schema, and file persistence suites.

Rationale

WordPress Playground and similar environments may not have native SQLite/PDO support available. A pure-PHP fallback makes the integration usable in those environments while preserving the existing PDO-based path where native SQLite is available.

Concurrency is intentionally conservative. The pure-PHP engine is not trying to emulate SQLite’s full pager, WAL mode, MVCC, or cross-process read/write scheduling. It serializes writes with a database-level lock and uses transaction snapshots to avoid lost updates. That is enough for the fallback runtime this PR targets, but it is not a high-concurrency database engine and should not be presented as one.

Implementation

The pure-PHP path stores database state as PHP arrays and persists it for file-backed databases. WP_PHP_Engine_PDO exposes enough PDO behavior for the existing driver stack, including legacy PHP/PDO fetch quirks covered by the package matrix.

Concurrency support is limited to correctness-oriented safeguards. For a file-backed database, overlapping writes behave like this:

1. The first writer takes an exclusive flock() on the database file.
2. Before applying the write, it reloads the latest committed file state so it does not overwrite changes committed by a previous connection.
3. The write runs against the in-memory PHP array state.
4. On success, the full database state is serialized back to the file with a new generation token, then the lock is released.
5. A second writer that starts while the first writer holds the lock waits up to the configured busy timeout (PDO::ATTR_TIMEOUT, or PRAGMA busy_timeout in milliseconds). If the lock is released in time, it reloads the just-written generation before applying its own changes. If not, it fails with SQLite-compatible code 5, database is locked.

Explicit transactions hold that exclusive lock from BEGIN until COMMIT or ROLLBACK. Reads from other file-backed connections take a shared lock and use the same busy-timeout behavior: they wait while a write transaction is open, then either reload the committed generation before reading or fail with database is locked if the timeout expires. ROLLBACK restores the transaction snapshot and releases the lock without exposing intermediate writes.

For :memory: databases, this is just a per-connection in-memory engine. There is no cross-connection shared database and therefore no cross-connection write coordination.

Known concurrency shortcomings:

• no row/page-level locks;
• no WAL-style concurrent writer plus readers model;
• no full MVCC snapshot isolation across independent processes;
• no deadlock detection, fairness guarantee, or lock wait tuning beyond the busy timeout;
• write-heavy workloads will bottleneck on the single database lock.

Testing instructions

./vendor/bin/phpunit --configuration packages/mysql-on-sqlite/phpunit.xml.dist --colors=never
./vendor/bin/phpcs --standard=phpcs.xml.dist \
  packages/mysql-on-sqlite/src/php-engine/class-wp-php-engine.php \
  packages/mysql-on-sqlite/src/php-engine/class-wp-php-engine-parser.php \
  packages/mysql-on-sqlite/src/php-engine/class-wp-php-engine-evaluator.php \
  packages/mysql-on-sqlite/src/php-engine/class-wp-php-engine-functions.php \
  packages/mysql-on-sqlite/src/php-engine/class-wp-php-engine-pdo.php \
  packages/mysql-on-sqlite/src/php-engine/class-wp-php-engine-pdo-statement.php \
  packages/mysql-on-sqlite/src/sqlite/class-wp-pdo-mysql-on-sqlite.php
git diff --check

CI is expected to pass across the full package PHP/SQLite matrix, WordPress PHPUnit, WordPress e2e, code style, and proxy tests.

[adamziel]

Fair local benchmark (same WordPress SQLite driver stack, only backend swapped):

• Machine: Apple M4 Max, arm64
• PHP: 8.4.5 CLI, opcache disabled, JIT disabled
• Storage: in-memory for both backends (sqlite::memory: vs php-engine::memory:)
• Method: one warmup run excluded; 5 measured runs; median reported
• Workload per run through WP_SQLite_Driver: create 5 schema objects, 250 wp_options inserts, 250 point selects, one grouped select, 250 wp_posts inserts, 250 wp_postmeta inserts, one join with ORDER BY ... LIMIT, one delete, one count.

Backend	Median	Runs
SQLite PDO	0.1386s	0.1374, 0.1386, 0.1382, 0.1393, 0.1395
Pure-PHP engine	0.4960s	0.4898, 0.6819, 0.4921, 0.5002, 0.4960

Result: on this small in-memory WordPress-ish workload, the pure-PHP engine is ~3.6x slower than SQLite PDO. This is intended as an apples-to-apples backend comparison through the same driver/translation layer, not as a production throughput claim.