SQLite test installs break with sqlite-database-integration 3.1 storage #372

Problem

With WP_CLI_TEST_DBTYPE=sqlite, Given a WP installation fails against the current sqlite-database-integration 3.1 plugin. Two spots in src/Context/FeatureContext.php predate the 3.1 randomized storage layout.

First, the install cache explicitly copies wp-content/database/.ht.sqlite to and from the cache. Version 3.1 stores the database in a randomized .ht.<secret>/.ht.sqlite file recorded in db-path.php, so the legacy file no longer exists. The copy emits a warning, Behat converts it to a step failure, and every scenario in the feature fails in the Background step:

Warning: copy(/tmp/wp-cli-test-run--XXXX/wp-content/database/.ht.sqlite): Failed to open stream: No such file or directory in vendor/wp-cli/wp-cli-tests/src/Context/FeatureContext.php

Second, copy_dir() shells out to cp -r %s/*, whose glob skips dotfiles. The randomized storage directory is therefore silently dropped both when caching a fresh install and when restoring one. The recorded db-path.php uses __DIR__, so restored caches would remain portable if the directory were copied whole.

Repro

Set WP_CLI_TEST_DBTYPE=sqlite and run any @require-sqlite feature that installs WordPress, for example the import suite in Automattic/wp-cli-sqlite-command. Every scenario fails before its first step with the warning above.

Suggested fix

Guard both legacy copies with file_exists, since dir_diff_copy() already captures the whole database directory including the randomized path. Change the directory copy to include hidden files, for example cp -r src/. dest instead of cp -r src/* dest, so the 3.1 storage directory survives caching and restoring. I verified locally that both changes together make a full Behat suite pass against the 3.1 driver; neither change affects the MySQL paths.