Drop legacy SQLite driver support

Start by locating SQLiteDatabaseIntegrationLoader, SQLiteDriverFactory, Export, Tables, and the related Behat scenarios, then verify that the released 3.0 plugin is available in the test environment. Review the compatibility paths and coordination checklist before changing them. Done means the legacy API paths and flags are removed or deliberately deprecated, documentation and fixtures are updated, and the full Behat suite passes against supported PHP and WordPress versions.

Context

Once SQLite Database Integration PR 449 is released and version 3.0 is the minimum supported plugin version, WP_MySQL_On_SQLite can become the only supported driver API. The compatibility paths introduced or retained in PR 33 can then be removed.

Work

• Raise the minimum SQLite Database Integration version to 3.0 and provide a clear error for older releases.
• Simplify SQLiteDatabaseIntegrationLoader to the supported 3.0 entry point; remove the legacy translator, old AST wrapper, single-file, and manual-loader fallbacks that are no longer needed.
• Simplify SQLiteDriverFactory to always construct WP_MySQL_On_SQLite; retain centralized DSN escaping and PDO attribute setup.
• Remove WP_SQLITE_AST_DRIVER handling and the --enable-ast-driver option from import, export, and tables.
• Decide whether to remove the CLI option immediately or temporarily accept it as a deprecated no-op for downstream compatibility.
• Replace driver union types and remove imports, branches, and PHPStan stubs for WP_SQLite_Translator, WP_SQLite_Driver, and—if no longer used—WP_SQLite_Connection.
• Simplify PDO result handling in Export and Tables; remove legacy array-result branches, legacy sorting, and internal-table filtering that the 3.0 driver already handles.
• Reconsider Export::get_sqlite_pdo(). If the PDO-like driver can stream rows without materializing them, query it directly and remove access to the underlying SQLite PDO; otherwise keep the accessor without its legacy branch and document the performance reason.
• Remove or convert flag-specific Behat scenarios so the normal, unflagged path covers import, export, tables, identifier quoting, SQL modes, and byte-preserving round trips.
• Update README, command help, architecture notes, and contributor documentation to describe a single driver API.

Test fixture cleanup

The export fixtures currently create setup SQL files and run wp sqlite import so table creation goes through the selected compatibility driver and updates its information schema. Once 3.0 is the only supported layout, consider loading WP_MySQL_On_SQLite from a persistent test-plugin path and instantiating it directly with each scenario's DSN. The fixtures could then execute setup DDL through the driver without temporary files or coupling export tests to the import command.

The persistent path matters because the Behat process survives across scenarios while individual scenario directories are deleted.

Coordination

• Confirm downstream consumers no longer depend on --enable-ast-driver or plugin versions below 3.0.
• Land the cleanup only after the 3.0 plugin release is available to the normal test environment.
• Run the full Behat suite against the released 3.0 plugin and supported PHP/WordPress versions.