mysql_cdc: write checkpoint after snapshot

[josephwoodward]

Currently after the snapshot the first time we checkpoint is after the first batch has been processed. This change ensures we checkpoint right after snapshotted data is flushed before we start streaming change records.

Closes: #4257

[claude]

Commits
LGTM

Review
This PR adds a snapshot completion sentinel event to ensure the checkpoint cache is updated immediately after all snapshot rows are flushed, rather than deferring until the first streaming batch is processed. The implementation sends a messageOperationSnapshotComplete event through the existing rawMessageEvents channel, and readMessages handles it by flushing any partial batch, tracking a checkpoint entry with immediate resolution, and persisting the binlog position. The thread-safety reasoning is sound: snapshot batch ack functions never write to the cache (nil offset), and streaming has not started at this point.

LGTM

[claude]

Commits
LGTM

Review
This PR adds a snapshot-completion sentinel event to the MySQL CDC input so that the binlog checkpoint is persisted immediately after all snapshot rows are flushed, rather than waiting for the first streaming batch. The logic — flush remaining batch, track a checkpoint entry with immediate resolution, and clear the timed-batch timer — is sound.

1. No tests cover the new snapshot-completion checkpoint path. Non-trivial logic (sentinel dispatch, batch flush, checkpoint tracking with immediate resolveFn() call) should have at least a unit test verifying the cached position advances after snapshot completion. See inline comment.

[claude]

Commits
LGTM

Review
This PR adds a snapshot completion sentinel event (messageOperationSnapshotComplete) that flushes any partial batch and writes a checkpoint to the cache immediately after the snapshot finishes, rather than deferring until the first CDC batch is acknowledged. The approach is sound — the Track-then-immediately-resolve pattern is consistent with the checkpoint library's API, and the concurrency reasoning (no mutex needed because snapshot batch ack callbacks never write to cache) holds.

1. Missing tests for snapshot completion checkpoint logic — The new code path in readMessages (input_mysql_stream.go L704-L731) adds non-trivial checkpoint management (flush + track + resolve + cache write) with no corresponding test. Existing integration tests exercise snapshot+CDC flows but don't verify the checkpoint cache state after snapshot completion.