phpMyAdmin fails after switching a Studio site to external MySQL

### Quick summary

After following Studio's documented procedure to switch a site from SQLite to an external MySQL server, the phpMyAdmin action remains available. Opening it fails because Studio's bundled phpMyAdmin integration is still configured exclusively for the removed SQLite database and driver.

### 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. Configure wp-config.php to use an external MySQL server and import the site's database.
5. Start the site and verify that WordPress is using MySQL. The DB_NAME issue currently requires the workaround described in #4672.
6. From the Studio site overview or Open in menu, click phpMyAdmin.

phpMyAdmin fails to load because it still attempts to initialize the removed SQLite database and SQLite integration driver.

### What you expected to happen

Either phpMyAdmin should connect to the external MySQL database configured in wp-config.php, or Studio should disable/hide the phpMyAdmin action for external-MySQL sites and explain that a separate database client is required. We could also include an "Open in..." link for database applications like TablePlus that users could change from the default phpMyAdmin

### What actually happened

The phpMyAdmin action remains visible and enabled, but the bundled integration is hard-coded to load Studio's SQLite database and SQLite driver. Because those files were intentionally removed during the documented MySQL migration, phpMyAdmin cannot load.

### 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

Related external-MySQL DB_NAME report: #4672

The current v1.19.0 source appears to confirm that the bundled phpMyAdmin integration only supports SQLite:

- apps/cli/lib/native-php/phpmyadmin.ts always generates a database environment with type sqlite and paths to wp-content/database/.ht.sqlite and the SQLite integration driver:
https://github.com/Automattic/studio/blob/v1.19.0/apps/cli/lib/native-php/phpmyadmin.ts#L29-L45
- apps/cli/php/DbiMysqli.php describes itself as an adapter for the MySQL-on-SQLite driver, loads WP_SQLite_Driver, and rejects non-SQLite database types:
https://github.com/Automattic/studio/blob/v1.19.0/apps/cli/php/DbiMysqli.php#L4-L40
https://github.com/Automattic/studio/blob/v1.19.0/apps/cli/php/DbiMysqli.php#L269-L275

The documentation describes phpMyAdmin as adapted for Studio's SQLite database, but the separate external-MySQL instructions do not warn that the phpMyAdmin action will no longer work:
https://developer.wordpress.com/docs/developer-tools/studio/frequently-asked-questions/#how-can-i-manage-the-studio-sites-sqlite-database
https://developer.wordpress.com/docs/developer-tools/studio/frequently-asked-questions/#how-can-i-use-studio-with-the-mysql-server-of-my-choice

A practical workaround is to connect to the external server using a separate phpMyAdmin installation, Adminer, TablePlus, or MySQL Workbench.

Start with apps/cli/lib/native-php/phpmyadmin.ts and apps/cli/php/DbiMysqli.php, then reproduce the documented SQLite-to-MySQL migration and open phpMyAdmin from the Studio site overview. Confirm whether the intended result is external-MySQL support or a disabled action with guidance; done means the action no longer fails silently for migrated sites.

Written by the indexing model from the issue text.