test(mysql): eliminate temporary database lifecycle flake in parallel migration tests

[AptS-1547]

What happened?

The MySQL migration integration suite can fail under parallel execution while creating or connecting to a per-test temporary database. The same failed test passes when rerun in isolation, which points to test-fixture database lifecycle jitter rather than a migration behavior regression.

Observed on commit 89761cb6135f8678d2260d82c6403ce69f48cefa while reviewing the upload-session migration work. No credentials or private endpoints are included below.

Steps to reproduce

1. Start the repository test dependencies used by the platform migration tests.

2. Run the migration matrix with normal nextest concurrency:

   cargo nextest run --profile ci --test platform migrations::

3. Observe an intermittent failure while a MySQL fixture applies the current schema.

4. Rerun the failed case in isolation:

   cargo nextest run --profile ci --test platform canonical_revision_ledger_mysql_downgrade_rejects_case_collisions_before_schema_changes

5. The isolated rerun passes.

Expected behavior

Each parallel MySQL migration test owns an independent temporary database whose create, connect, migrate, rollback, and drop lifecycle cannot interfere with another test. Repeated parallel runs should remain deterministic.

Actual behavior

One parallel matrix run completed 38 of 39 migration tests and failed this case before its migration assertion:

aster_drive::platform migrations::canonical_revision_ledger_mysql_downgrade_rejects_case_collisions_before_schema_changes

current MySQL schema should apply:
Exec(SqlxError(Database(MySqlDatabaseError {
  code: Some("42000"),
  number: 1049,
  message: "Unknown database 'asterdrive_it_<unique_suffix>'"
})))

The exact isolated rerun then passed 1/1. The failure occurs during temporary database setup/availability, before validating the canonical revision ledger downgrade behavior.

Suspected boundary

The fixture should be audited around:

• temporary database name allocation;
• CREATE DATABASE completion before opening the test connection;
• connection-pool reuse across fixture generations;
• teardown ordering and outstanding handles;
• cleanup code dropping only the database owned by that fixture;
• nextest process/thread concurrency against the shared MySQL container.

This is a hypothesis boundary, not a confirmed root cause.

Acceptance criteria

• Parallel MySQL migration fixtures have explicit ownership of unique database names.
• Database creation is confirmed before connecting or applying migrations.
• Teardown waits for fixture-owned connections and does not race another test lifecycle.
• Failures log redacted create/connect/drop phase evidence and the fixture identifier.
• A repeated parallel stress run of the MySQL migration subset completes without 1049 Unknown database failures.
• The isolated canonical-ledger downgrade test remains green.
• SQLite and PostgreSQL migration tests remain green.
• Temporary databases are removed after success and failure.

Suggested stress gate:

for run in $(seq 1 20); do
  cargo nextest run --profile ci --test platform migrations:: || exit 1
done

Environment

• Installation method: built from source
• Database backend: MySQL test container
• Test runner: cargo-nextest, CI profile
• Storage backend: not storage-related
• Checkout: 89761cb6135f8678d2260d82c6403ce69f48cefa

Checklist

• Searched existing issues for duplicates; test(reliability): establish deterministic crash-recovery validation for persisted workflows #522 covers process crash recovery, not temporary MySQL database lifecycle races.
• Checked current test and migration documentation.
• Removed credentials, private endpoints, and the concrete random database suffix.