Preserve custom db.php drop-ins during SQLite integration updates

[chubes4]

Summary

• Adds hasCustomDbDropin() method to detect custom database drop-ins that extend the SQLite integration
• Skips overwriting db.php when a custom drop-in is detected, preserving plugins like markdown-database-integration
• Still updates the SQLite mu-plugin (custom drop-ins depend on its driver classes)

Problem

keepSqliteIntegrationUpdated() unconditionally overwrites wp-content/db.php with the stock SQLite drop-in on every site start, import, export, push, and pull. This makes it impossible to use a custom db.php that extends WP_SQLite_DB / WP_SQLite_Driver.

The markdown-database-integration plugin provides a custom db.php that uses in-memory SQLite with markdown files as the source of truth. Every time Studio touches the site, it reverts to the stock drop-in, causing data loss (markdown-stored posts become invisible).

Detection Logic

A custom drop-in is identified by two conditions:

1. It defines SQLITE_DB_DROPIN_VERSION (so the SQLite plugin recognizes it as a valid drop-in)
2. It does not contain the stock header comment "This file is auto-generated and copied from the sqlite plugin"

This correctly distinguishes:

• Stock db.php → overwrite as before ✅
• Custom db.php (e.g. markdown-database-integration) → preserve ✅
• No db.php → create from db.copy as before ✅

Testing

• 46 unit tests pass (including 6 new tests for custom drop-in detection and preservation)
• Verified detection logic against both stock and custom db.php files

Fixes #3094

[wpmobilebot]

📊 Performance Test Results

Comparing 1995062 vs trunk

app-size

Metric	trunk	1995062	Diff	Change
App Size (Mac)	1282.03 MB	1282.16 MB	+0.13 MB	⚪ 0.0%

site-editor

Metric	trunk	1995062	Diff	Change
load	1890 ms	1897 ms	+7 ms	⚪ 0.0%

site-startup

Metric	trunk	1995062	Diff	Change
siteCreation	9106 ms	9089 ms	17 ms	⚪ 0.0%
siteStartup	4186 ms	4931 ms	+745 ms	🔴 17.8%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[wojtekn]

@chubes4 FYI, I'm working on removing the responsibility of managing SQLite from Studio in favor of relying on Playground CLI behavior (#3072), so we may need to reassess how loading custom db.php works with the default Playground. Maybe it will work OOTB?

[chubes4]

@wojtekn sounds like it would work out of the box for my use case. In the meantime I am running this patch locally to test the Markdown database integration. Otherwise all the posts get wiped every time the site restarts.

[chubes4]

@wojtekn since #3072 is now a draft, and this is an active blocker for database drop-in experiments, can we consider using this fix for now?