SQLite path resolution misses db-path.php secret path #353

Problem

DB_Command_SQLite::get_sqlite_db_path() (src/DB_Command_SQLite.php:65-99) only checks, in order:

1. FQDB constant,
2. FQDBDIR + DB_FILE, defaulting to <wp-content>/database/.ht.sqlite,
3. a few hardcoded legacy fallbacks.

Since sqlite-database-integration 3.1, the canonical resolution lives in the drop-in (wp-includes/sqlite/db.php:50-56):

if ( defined( 'DB_PATH' ) ) {
    $database_storage = WP_SQLite_Storage::with_explicit_path( DB_PATH );
} elseif ( defined( 'FQDB' ) ) {
    $database_storage = WP_SQLite_Storage::with_explicit_path( FQDB );
} else {
    $database_storage = WP_SQLite_Storage::with_secret_path( FQDBDIR );
}

with_secret_path() reads the recorded randomized path from db-path.php (class-wp-sqlite-storage.php:118-126,386-407), migrating legacy .ht.sqlite (:204-210). Sites that set an explicit DB_PATH outside the web root (in our case, .local/sqlite/wordpress.sqlite via WP_DB_PATH) cannot be located by wp db * file-path operations whenever the drop-in has not yet defined FQDB. Until then, wp db export, size, and reset resolve the wrong file or report a missing database.

The sibling package already handles this. See Automattic/wp-cli-sqlite-command/src/SQLiteDriverFactory.php:46-78, which resolves DB_PATH → FQDB → FQDBDIR/db-path.php (@include) → legacy .ht.sqlite → with_secret_path(FQDBDIR)->initialize().

Proposed change

The same chain should be mirrored in get_sqlite_db_path(): check DB_PATH first, then FQDB, then @include FQDBDIR/db-path.php, then legacy .ht.sqlite. Alternatively, once the drop-in is loaded, the function could return the already-resolved FQDB, which the drop-in re-defines from the resolved path at db.php:75-77.

Repro

Set DB_PATH to a file outside wp-content/database, with no FQDB defined yet at the point wp db resolves the path. Run any wp db file-path subcommand. It targets <wp-content>/database/.ht.sqlite.