Native PHP runtime forces external MySQL database name to wordpress

### Quick summary

After following the documented procedure to switch a Studio-created site from SQLite to an external MySQL server, Studio forces DB_NAME back to wordpress during site startup. This prevents multiple Studio sites from using separate databases on the same MySQL server and conflicts with the documentation, which says to fill wp-config.php with the chosen MySQL server credentials.

### Steps to reproduce

1. Create a site in the Studio app using the Native PHP runtime.
2. Stop the site.
3. Follow the documented SQLite-to-MySQL procedure: remove wp-content/db.php, wp-content/database, and the SQLite integration under wp-content/mu-plugins.
4. Create an external MySQL database with a name other than wordpress, for example database_demo, and import the site database.
5. Set DB_NAME in wp-config.php to database_demo and provide the correct DB_HOST, DB_USER, and DB_PASSWORD values.
6. Start the site in Studio.
7. Inspect wp-config.php and attempt to load the site.

DB_NAME is changed to wordpress during startup. The site only works if the external database is also named wordpress.

### What you expected to happen

Studio should preserve the DB_NAME configured in wp-config.php and connect to that database. A single MySQL server should be able to host multiple Studio sites using separate database names.

### What actually happened

Studio changes DB_NAME to wordpress when starting the site, so a custom external MySQL database name is ignored. Each site is effectively required to use a database named wordpress.

### App or CLI?

Studio App

### Version

1.19.0

### Impact

Some (< 50%)

### Available workarounds?

Yes, easy to implement

### Platform

Mac

### Architecture

ARM64 (Apple Silicon, Windows or Linux on ARM)

### Logs or notes

The current v1.19.0 source appears to explain the behavior:

- apps/cli/lib/native-php/site-setup.ts defines DEFAULT_WP_CONFIG_CONSTANTS as DB_NAME: wordpress and passes it to WP_Config_Transformer:
https://github.com/Automattic/studio/blob/v1.19.0/apps/cli/lib/native-php/site-setup.ts#L20-L68
- apps/cli/php-server-child.ts calls ensureWpConfig during startup for ordinary native-runtime sites:
https://github.com/Automattic/studio/blob/v1.19.0/apps/cli/php-server-child.ts#L494-L508
- The transformer replaces existing constant values:
https://github.com/Automattic/studio/blob/v1.19.0/apps/cli/php/wp-config-transformer.php

The hard-coded fallback was introduced for SQLite in PR #3172, but it does not appear to be conditional on the site still using SQLite:
https://github.com/Automattic/studio/pull/3172

External MySQL documentation:
https://developer.wordpress.com/docs/developer-tools/studio/frequently-asked-questions/#how-can-i-use-studio-with-the-mysql-server-of-my-choice

Start with apps/cli/lib/native-php/site-setup.ts and apps/cli/php-server-child.ts to trace how ensureWpConfig receives configuration during Native PHP startup, then read apps/cli/php/wp-config-transformer.php. Compare this flow with the SQLite-specific behavior from PR #3172. Done means an external MySQL site preserves its configured DB_NAME and can start with a database name other than wordpress.

Written by the indexing model from the issue text.