Overwrite db.php before importing database

[grgar]

Ensure SQLite integration is in place since importing database reads file to determine version.

Related issues

• Fixes "Could not determine the version of the SQLite integration plugin" on pull of database from WordPress.com site #3518

How AI was used in this PR

This was my own work. I asked AI to investigate the problem from the issue and it made some random changes that didn't make any difference.

Proposed Changes

The database import reads SQLITE_DB_DROPIN_VERSION but which doesn't exist, because db.php got overwritten by the import as I have Query Monitor plugin installed on my WordPress.com site. Therefore, recreate db.php before importing the database (at the expense of Query Monitor no longer having its drop-in db.php active).

Testing Instructions

I only have one paid site (my personal site) on WordPress.com, so I tested by

1. Having Query Monitor installed on a site.
2. Pulling it into a new site created in Studio.
3. Error from "Could not determine the version of the SQLite integration plugin" on pull of database from WordPress.com site #3518 does not occur.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[grgar]

Regression test added as requested on #3518

[chubes4]

The Query Monitor regression is fixed, but the unconditional SQLite installation bypasses the intentional-MySQL policy established in #3993.

Before import, a destination with wp-config.php and none of these SQLite artifacts is classified as intentionally using MySQL:

• wp-content/db.php
• wp-content/database/.ht.sqlite
• wp-content/mu-plugins/sqlite-database-integration/

I reproduced that topology with the real CLI and the repository's jetpack-backup.tar.gz fixture. When the empty wp-content/database/ directory remained, the import exited successfully and recreated all three SQLite artifacts, including a 528384-byte .ht.sqlite database. On trunk the same topology fails rather than converting the database engine.

The sequence causing this is BaseBackupImporter.import() creating .ht.sqlite before BaseImporter.importDatabase() unconditionally calls installSqliteIntegration(). By that point, the artifact used to distinguish intentional MySQL has already been synthesized.

Please preserve the destination's database-engine classification before import cleanup/database creation, and only reinstall SQLite for a destination that was classified as SQLite. An E2E case with all three SQLite artifacts absent would protect the #3993 contract alongside the new Query Monitor regression test.

For clarity, this does not regress a currently successful MySQL import: trunk fails that import. The regression is replacing the visible failure with a successful, silent conversion to SQLite.

[chubes4]

@grgar I am going to take over here to get this fix landed. Hope that's alright with you.

[chubes4]

The follow-up fix is complete and verified, but GitHub still reports chubes4 with read-only (pull) access to grgars/studio; a dry-run push to fix-sqlite returns HTTP 403.

Ready commit: 9164650cc

This commit classifies the destination before any import mutation, rejects external/MySQL database imports explicitly, and adds the intentional-MySQL non-mutation E2E case. Verification against current trunk:

• focused unit tests: 58 passed
• CLI typecheck: passed
• real CLI import E2E suite: 7 passed, including Query Monitor replacement and MySQL preservation

@grgar could you either grant chubes4 Write repository access or cherry-pick 9164650cc onto fix-sqlite? Once write access is active I can push it directly.

AI assistance disclosure: OpenAI GPT-5.6 Sol via OpenCode implemented the follow-up under my direction; I reviewed and verified the resulting change.

[chubes4]

Replacement PR is now open from a current, pushable Automattic branch: #4356.

George's two commits are preserved with original authorship, followed by the destination-classification fix and MySQL non-mutation E2E coverage. I suggest moving review to #4356.