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.

先定位 SQLiteDatabaseIntegrationLoader、SQLiteDriverFactory、Export、Tables 以及相關的 Behat 情境，然後確認已發布的 3.0 外掛程式在測試環境中可用。在變更相容性路徑和協調檢查清單之前，先進行檢視。完成的標準是：移除 legacy API 路徑和 flags，或刻意將其標記為已棄用；更新文件和 fixtures；並且完整的 Behat 套件在受支援的 PHP 和 WordPress 版本上通過。

由索引模型根據 Issue 內容生成。