Adding unique indexes causes data loss even when using PanicOnWarnings

[ggilder]

gh-ost can silently lose data when adding a unique index to a column during a migration, even with the PanicOnWarnings flag enabled. This can occur when:

1. A migration adds a unique index to a column (e.g., email)
2. Rows with duplicate values are inserted into the original table after the
   bulk copy phase completes (during postponed cutover)
3. These duplicate rows are applied via binlog replay to the ghost table

Expected behavior: Migration fails with clear error
Actual behavior: Original rows with duplicate values silently deleted, data lost

Example:

Original table: id PRIMARY KEY, email (no unique constraint)
Ghost table: id PRIMARY KEY, email UNIQUE (being added)

Initial state (after bulk copy):

• Ghost table: (id=1, email='bob@example.com')
  (id=2, email='alice@example.com')

During postponed cutover:

• INSERT (id=3, email='bob@example.com') into original table

Binlog replay attempts:

• INSERT (id=3, email='bob@example.com') into ghost table
• Duplicate email='bob@example.com' (conflicts with id=1)
• Row with id=1 silently deleted → DATA LOSS

This is not caught by PanicOnWarnings because gh-ost uses REPLACE for binlog replay, which does not produce warnings or errors when overwriting a row that's considered a duplicate.