Push fails with "The database failed to import on the live site" due to collation mismatch

### Quick summary

Pushing a Studio site to a WordPress.com (Atomic) production site fails with the generic error "The database failed to import on the live site. Review your database and try again."

Root cause (verified locally): a table created *locally* in Studio was recorded in the SQLite integration's information-schema mirror with `TABLE_COLLATION = utf8mb4_0900_ai_ci` (a MySQL 8.0-only collation). On push, the SQL export reconstructs `CREATE TABLE` statements via `SHOW CREATE TABLE` and unconditionally appends `DEFAULT CHARSET=... COLLATE=utf8mb4_0900_ai_ci`. The WordPress.com import target (MariaDB) does not support that collation, so the import aborts. Studio surfaces only the generic message, with no hint of the failing statement.

Code pointers:

- `Resources/cli/wp-files/sqlite-command/src/Export.php` — export uses `SHOW CREATE TABLE`
- `sqlite-database-integration` (3.0.0-rc.8) `class-wp-mysql-on-sqlite.php`, CREATE TABLE reconstruction — emits `DEFAULT CHARSET=%s` + `COLLATE=%s` from the info-schema mirror with no MariaDB-compatibility mapping

Notes: tables pulled from the live site kept MariaDB-safe collations (`utf8mb4_unicode_ci`, `utf8mb4_unicode_520_ci`, `latin1_swedish_ci`); only a table created locally (by a plugin using dbDelta / `$wpdb->get_charset_collate()`) was recorded with `utf8mb4_0900_ai_ci`. The column-level mirror (`..._information_schema_columns`) records `utf8mb4_0900_ai_ci` for every column, though the exporter currently only emits the table-level collation.

Identical failures across multiple attempts on different days (Aug 18 ×2, Aug 23 ×2). Local export provably contained the MySQL-8-only collation on one table.

### Steps to reproduce

1. Connect a Studio site to a WordPress.com Atomic production site and pull it (files + database).
2. Locally, install/activate a plugin that creates a custom table (dbDelta with `$wpdb->get_charset_collate()`). In my case the table was recorded in `_wp_sqlite_mysql_information_schema_tables` with `utf8mb4_0900_ai_ci`.
3. Push to production with "All files and folders" + "Database" checked.
4. Export verification (without pushing): run a database export for the site and inspect the generated SQL — it contains `CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;`

### What you expected to happen

- The export should emit MariaDB-compatible DDL for WordPress.com/Pressable targets (e.g. map `utf8mb4_0900_*` → `utf8mb4_unicode_ci`), or the driver should not default locally-created tables to a MySQL 8-only collation.
- If the remote import fails, Studio should surface the actual server-side error (e.g. "Unknown collation") instead of the generic message.

### What actually happened

Push fails at the database-import stage every time:

```
[2026-08-18T16:33:05.693Z][erro][main] Error occurred in handler for 'pushSiteToLive': Error: The database failed to import on the live site. Review your database and try again.
at waitForImport (.../app.asar/dist/main/index.js:50418:43)
```

### App or CLI?

Studio App

### Version

1.18.0 (updating to 1.20.0 didn't resolve the issue)

### Impact

One

### Available workarounds?

Yes, difficult to implement

Requires manual surgery on the info-schema mirror (site stopped), then push:

```sql
UPDATE _wp_sqlite_mysql_information_schema_tables SET TABLE_COLLATION='utf8mb4_unicode_ci' WHERE TABLE_NAME='';
```

### Platform

Mac

### Architecture

ARM64 (Apple Silicon, Windows or Linux on ARM)

### Logs or notes

- Studio 1.18.0 (production, commit 121b18d77f96e4362c7d22bdcd4c428022503f8b), macOS 26.6.1
- sqlite-database-integration 3.0.0-rc.8 (AST driver), local PHP 8.4
- Remote: WordPress.com Atomic production site (~420 MB payload)

Happy to provide the site URL / blog ID privately for backend correlation.

Start with Resources/cli/wp-files/sqlite-command/src/Export.php and the sqlite-database-integration 3.0.0-rc.8 class-wp-mysql-on-sqlite.php CREATE TABLE reconstruction. Run a database export for a site containing a locally created table and inspect its collation DDL. Done means the generated SQL is accepted by the MariaDB import target, with the relevant failure surfaced if import still fails.

Written by the indexing model from the issue text.