[CharlieW-22]

Fixes #1793

Description

On --resume and --revert, gh-ost starts the binlog reader at a checkpoint before it registers the DML listener for the original table. Row events for that table read in between are never decoded or queued. So changes made while gh-ost was stopped (resume), or after the cut-over (revert), never reach rows that are already in the target table, and gh-ost cuts over and exits 0 with stale rows. The details and a standalone reproduction are in #1793.

This PR registers the listener inside initiateStreaming(), before InitDBConnections() starts the reader, when resuming or reverting. It also removes the later registration on those two paths: Migrate() skips it when resuming, and Revert() no longer calls it.

Fresh migrations are unchanged. They keep the current order on purpose: there, the streamer has to deliver the GhostTableMigrated changelog event before anything drains applyEventsQueue, so an early DML listener could fill the queue and hold that event back.

Things I checked:

• A backlog bigger than the queue. On the resume and revert paths, nothing waits on the streamer before the applier starts. So a backlog bigger than the 1,000-event applyEventsQueue just pauses the reader until executeWriteFuncs() (or executeDMLWriteFuncs()) drains it. I tried this locally with 3,000 changes waiting. The queue filled up during the hook, and both the resume and the revert finished with every change applied.
• The listener is registered once. --revert can't be combined with --resume, and Migrate() never runs in revert mode, so every path adds the listener exactly once.
• Other open PRs. The migrator.go change merges cleanly with Checkpoint only fully applied binlog transactions #1790, which changes what addDMLEventsListener() registers but not when it's called. Fix: --resume without --execute drops the ghost/changelog tables #1770 adds tests in the same place in migrator_test.go, so whichever of the two lands second will need a trivial rebase.

Tests

Two regression tests in MigratorTestSuite, both in GTID mode:

• TestResumeAppliesDMLWrittenWhileStopped checkpoints a migration while the cut-over is postponed and aborts it. It updates every third row while gh-ost is stopped, then resumes and cuts over. It then checks that the migrated table matches the old table row for row.
• TestRevertAppliesDMLWrittenAfterCutOver migrates, updates every third row after the cut-over, and reverts. It then checks that the reverted table matches the migrated one row for row.

Both resume or revert with a gh-ost-on-validated hook that runs sleep 1. The hook runs inside the gap, so the race is lost every time: on master, both tests failed in every run, with all 34 updated rows stale. With this change, both passed in every run (6 of 6). Together they add about 20 seconds to the suite, mostly the resume test waiting for its first checkpoint (10 seconds, the interval the other checkpoint tests use).

To run just these two (Docker needed, for the MySQL test container):

go test ./go/logic/ -run 'TestMigrator$' -testify.m 'TestResumeAppliesDMLWrittenWhileStopped|TestRevertAppliesDMLWrittenAfterCutOver' -v

I also ran these locally:

• script/cibuild passes, with Go 1.25.12 and the MySQL 8.0.42 test container.
• golangci-lint v2.11.4 reports no issues.
• script/docker-gh-ost-replica-tests passes all 90 tests on mysql:8.0.41, including gtid-resume, which also passes on mysql:8.4.3 and mariadb:11.8.8.
• The issue's standalone script (MySQL 8.0.45, file/position coordinates) lost no updates in any of 7 runs with this branch, including the hook, mid-copy, GOMAXPROCS=1 and exact-row-count cases. The official v1.1.11 binary lost updates in all 4 of its control runs on the same days.

In case this PR introduced Go code changes:

• contributed code is using same conventions as original code
• script/cibuild returns with no formatting errors, build errors or unit test errors.