Add Mysql provider

[ScarletKuro]

Closes #15

[adospace]

Thanks for this — it's a careful port. The provider mirrors the PostgreSQL one closely, netstandard2.0 matches the other providers, the trigger/CT design is faithful, and the 1:1
test parity with the PG suite (27 tests, no skips) is appreciated. CI is green: 126 passed, 0 failed.

One fix needed, and one follow-up ask.

1. EnableChangeTrackingForTable is missing InitializeStoreAsync (needs fixing)

MySqlSyncProvider.cs:831 goes straight from validation to resolving the table. All four existing providers initialize first — PostgreSQL :815, Sqlite :822, SqlServer :967,
SqlServerCT :768.

The call is load-bearing, not ceremonial. EnableChangeTrackingForTable → SetupTableForFullChangeDetection → CreateTriggerAsync builds the trigger from table.PrimaryColumnType and
table.PrimaryColumnName, and both resolve through Columns.First(_ => _.Value.IsPrimaryKey). Columns is only populated by InitializeStoreAsync — so calling
EnableChangeTrackingForTable as the first operation on a fresh provider throws InvalidOperationException: Sequence contains no matching element instead of creating the trigger.

Green CI doesn't clear this, and that's structural rather than a gap in the run: Test_MySql_MySql_TestSynchronizationAfterDisabledChangeTrackingForTable and friends all call
ApplyProvisionAsync and sync first, so _initialized is already true by the time that path runs. It only fails when it's the first call on a new instance, which no test does.

public async Task EnableChangeTrackingForTable(string name, CancellationToken cancellationToken = default)
{
Validate.NotNullOrEmptyOrWhiteSpace(name, nameof(name));

  await InitializeStoreAsync(cancellationToken);   // <-- add

  var table = Configuration.Tables.Cast<MySqlSyncTable>().FirstOrDefault(_ => _.Name == name);
  ...

}

DisableChangeTrackingForTable (:857) is correct as-is — dropping a trigger only needs the table name, which is why no provider initializes there.

2. Microting 9.0.8 pins the tests to an EOL runtime (follow-up)

Your point about Pomelo stands — its latest stable is still 9.0.0 on net8 with only a 10.0.0-preview.1, while Microting shipped 10.0.10 yesterday. No argument that it's the more
active fork, and since it's test-only (the shipped package depends solely on MySqlConnector), it never reaches consumers.

The issue is the version, not the fork. Microting.EntityFrameworkCore.MySql 9.0.8 publishes exactly one target — net9.0 — and that's what forced CoreSync.Tests from net8.0 →
net9.0, which in turn forced the workflow SDK to 9.0.x and Mvc.Testing to 9.0.7. But 9.0.8 is the fork's old line (published 2025-08-05), and net9 is STS whose support ended ~May
2026 — so the suite lands on an already-EOL runtime, while the net8 it's leaving is LTS through November 2026.

Microting 10.0.10 targets net10.0 and is current. Could you bump to it and take CoreSync.Tests to net10 instead of net9? Same dependency, same reasoning, current LTS rather than a
dead one — and it matches the README's "netstandard2.0 covers everything up to .NET 10" claim. Happy to take that as a separate PR if you'd prefer to keep this one focused.

[ScarletKuro]

The issue is the version, not the fork. Microting.EntityFrameworkCore.MySql 9.0.8 publishes exactly one target — net9.0 — and that's what forced CoreSync.Tests from net8.0 →
net9.0, which in turn forced the workflow SDK to 9.0.x and Mvc.Testing to 9.0.7. But 9.0.8 is the fork's old line (published 2025-08-05), and net9 is STS whose support ended ~May

Any source that .net9 support ended in May?
Both .net8 and .net9 end of life is November 10, 2026 https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/

Anyway, I will address your comments later.

[adospace]

Yes, sorry, ends at Nov 2026. Feel free to leave it as is at net 9; I need to move the tests project to net 10 in November, anyway.