fix(db): preserve renamed migration compatibility

[jiashuoz]

Summary

Follow-up to #958 for databases that already recorded the sending-protection migrations under their former filenames.

• treat legacy tracker filenames as equivalent to the renumbered 112-118 files without replaying migration SQL
• atomically record current and legacy markers on fresh installs and heal current-only states in auto mode
• fail verify mode when rollback compatibility markers need repair
• make readiness accept the same filename equivalence so legacy-only upgrades can enter service
• keep orphan warnings for unknown filenames while suppressing only registered aliases whose current file exists

Verification

• focused none / legacy-only / current-only / both tracker-state matrix
• injected no-transaction tracker failure proves alias markers are atomic
• legacy-only readiness regression
• go test -p 1 ./...
• make test-integration

[AmirF194]

e2a-prober validate's own docstring says it checks "migrations applied", but it calls migrationsApplied(), which runs RunMigrations(ModeVerify). With this PR, ModeVerify hard-errors whenever migrationFilenameCompatibilityRepairs finds a current-only alias pair (migrate.go:192-197), even though the schema itself is fully migrated, just missing the defensive legacy tracker row.

ModeVerify never performs that repair, and none of e2a-prober's subcommands run ModeAuto, so validate has no way to clear this state by itself. Only cmd/e2a's own startup (default ModeAuto) resolves it. Meanwhile cmd/e2a's /readyz check, updated in this PR, is alias-aware via the ANY($1) query at readyz.go:293 and does not hit this.

Is the intent that e2a-prober validate only ever runs after cmd/e2a has started at least once at this version? If it can run first, for example as a manual check against a database migrated by an older binary, the error text "rollback compatibility repair pending" reads as a real migration gap when the schema is actually complete.