Add support for the new SQLite storage

[JanJakes]

Summary

Add support for the SQLite integration plugin's new database storage while keeping compatibility with older plugin releases. The commands now find the same database that WordPress uses:

• The database comes from DB_PATH, the legacy FQDB setting, the recorded secret path (db-path.php), or an existing .ht.sqlite file, in that order.
• Export and table listing require an existing database and never initialize or migrate database storage.
• Import creates a missing database. When no database path is configured or recorded and no legacy database exists, it initializes the new storage.
• An existing .ht.sqlite file is used as is. WordPress moves it to the new storage on its next load.
• Invalid database settings and in-memory databases fail with a clear error.

Behat covers the storage behavior. Separate commits correct the existing import fixtures for the current driver and align PHP compatibility checks with the project's PHP 7.4 requirement.

Why

These commands run before WordPress loads its database drop-in. With the new storage, FQDB is no longer always defined at that point, so the commands need to find the configured database themselves.

Testing

CI runs against the released plugin, which doesn't include the new storage yet.

Related: WordPress/sqlite-database-integration#502, WordPress/sqlite-database-integration#512

[brandonpayton]

As part of reviewing this, I had Claude tell me what it thinks, and I'll have it post here because some its points sound reasonable.

[brandonpayton]

🤖 This review was written by Claude (Claude Code), posted at @brandonpayton's request.

The direction is good. The resolution order (DB_PATH → FQDB → db-path.php → .ht.sqlite → initialize on import) makes sense, read commands no longer create storage as a side effect, and features/sqlite-storage.feature covers a lot of ground.

The main risk is that get_database_path() re-implements path resolution the plugin already owns, and a few edge cases come out differently. Details are in the inline comments. Roughly in priority order:

1. The legacy WP_SQLite_Translator branch ignores the resolved $database_path.
2. Import initializes storage in the constructor, before the dump file is opened.
3. Exceptions from driver construction aren't wrapped in WP_CLI::error.
4. A relative path from db-path.php resolves against the working directory, not FQDBDIR.
5. Smaller items: DB_FILE is ignored, DB_PATH takes precedence even on older plugins, the test helper reads FQDB without a defined() guard, and NO_BACKSLASH_ESCAPES coverage was removed.

Longer term: a read-only "resolve without initializing" method on WP_SQLite_Storage would let the CLI drop its own copy of the resolution logic, so it can't drift from the plugin. That would make items 1, 4, and most of 5 go away.

Minor: AGENTS.md asks for an add/, update/ or fix/ branch prefix and for commits to reference a PR or issue number. Neither is a blocker.

[JanJakes]

Thanks for the review, @brandonpayton! I forgot to mention the bigger plan to move this repo into the SQLite integration so that import/export and the plugin can ship together, and all this cross-version logic can go away. Here, I just need it to work for the 3.1 release. I made a few improvements based on your feedback and replied to the rest.

[brandonpayton]

@JanJakes I left one question, but this reads well to me.

[JanJakes]

Thanks for the thorough review! I'll go ahead and merge this one to prepare the 3.1 release. I will also try to make the migration of this repo to https://github.com/WordPress/sqlite-database-integration/ happen soon.