Drop legacy SQLite driver support

## Context

Once [SQLite Database Integration PR 449](https://github.com/WordPress/sqlite-database-integration/pull/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](https://github.com/Automattic/wp-cli-sqlite-command/pull/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.

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.

Written by the indexing model from the issue text.