[fix] make V181 migration idempotent and self-repair flyway history

[orangeCatDeveloper]

Fixes #4325

On a fresh MySQL/PostgreSQL database the manager can lock itself out: the first boot fails halfway through migration V181, and every boot after that refuses to start — until someone hand-deletes a row from flyway_schema_history.

Root cause: two schema managers run at startup, Hibernate (ddl-auto) first and Flyway second. Hibernate creates hzb_sop_schedule from the entity, so V181's bare CREATE TABLE collides. Flyway records that failure in its history table, and validation then rejects every subsequent start:

FlywayValidateException: Validate failed: Migrations have failed validation
Detected failed migration to version 181 (update column)

The fix has two halves. The scripts become idempotent (CREATE TABLE IF NOT EXISTS / CREATE INDEX IF NOT EXISTS in both mysql and postgresql variants), so racing Hibernate no longer fails the migration. And for instances already locked out, FlywayConfiguration catches this one validation failure ("failed migration"), runs flyway.repair() and retries once — other validation errors (e.g. checksum mismatch) still propagate, since those need a human decision.

FlywayConfigurationTest pins both behaviors with mocks (repair + retry ordering; checksum errors rethrown without repair).

Verified against real MySQL 8 and PostgreSQL 15 (Hibernate-created table first, then Flyway with production baseline settings):

before: 1st boot  V181 CREATE TABLE collides -> failure recorded
        2nd boot  FlywayValidateException: Detected failed migration to version 181  (locked out forever)

after:  fresh install with pre-existing table -> migrate succeeds
        already-broken history                -> repair + retry succeeds, instance starts

[Aias00]

评审结论：APPROVE

修复启动自锁的 Flyway 自修复方案，两部分互补且测试到位。

修复点确认：

1. 脚本幂等化：MySQL 与 PostgreSQL 的 V181 均改为 CREATE TABLE IF NOT EXISTS / CREATE INDEX IF NOT EXISTS，消除 Hibernate（ddl-auto）先建表、Flyway 后跑 V181 导致的 CREATE TABLE 冲突。
2. 启动自愈：delayedFlywayInitializer 捕获 FlywayValidateException——消息含 "failed migration" 时执行 flyway.repair() + 仅重试一次 migrate()；其余校验错误（如 checksum mismatch）仍直接抛出交由人工处理。仅一次重试，无无限循环风险。

测试： FlywayConfigurationTest 用 mock 钉死两种路径——失败迁移触发 migrate→repair→migrate 顺序、checksum mismatch 不 repair 直接重抛。

非阻塞说明：

• 靠异常 message 文本匹配 "failed migration" 属经验性做法；若 Flyway 未来改文案或本地化会失效。但测试已钉死当前确切文案，且兜底策略（不匹配就重抛）是安全的，可接受。

无阻塞问题，批准。