fix: resolve migration timestamp collisions

[MerlinTheWhiz]

Closes #22

Summary

Problem

Four pairs of migration files shared identical timestamp prefixes, making their apply order non-deterministic:

Collision	Files
1777000000007	loan-events-composite-indexes, unique-loan-status-events
1778000000008	quarantine-events, transaction-submissions
1786000000016	ensure-loan-events-loan-id-index, webhook-max-attempts
1788000000018	add-loan-events-missing-indexes, unified-contract-events

The 1788000000018 pair was most critical: add-loan-events-missing-indexes creates indexes on loan_events while unified-contract-events renames that table to contract_events. If they ran in the wrong order, the index creation would fail.

Changes

Renamed one file per colliding pair to a unique, strictly-increasing timestamp:

Before	After
1777000000007_unique-loan-status-events.js	1777000000008_unique-loan-status-events.js
1778000000008_transaction-submissions.js	1778000000009_transaction-submissions.js
1786000000016_webhook-max-attempts.js	1786000000017_webhook-max-attempts.js
1788000000018_unified-contract-events.js	1788000000019_unified-contract-events.js

All 27 timestamps are now unique and strictly increasing. The critical pair is correctly ordered — add-loan-events-missing-indexes (1788000000018) runs before unified-contract-events (1788000000019).

README — updated the core migrations table, added a migration naming convention section to prevent future collisions, and documented the exact SQL to fix pgmigrations on existing databases after the rename.

Verification

• All timestamps unique and strictly increasing
• Existing DB + renamed files: node-pg-migrate correctly blocks with order-check error
• Running the provided SQL to sync pgmigrations then allows migrate:up to succeed
• Documented convention to prevent future timestamp collisions

[ogazboiz]

this cleanly resolves all four migration timestamp collisions and the README notes on the fix are genuinely helpful, especially the bit about the pgmigrations tracking table for databases where the old-named migrations already ran. each collided pair has its second file bumped to the next number (007 to 008, 008 to 009, 016 to 017, 018 to 019), no duplicate prefixes remain and the ordering stays monotonic. i checked the dependency case too: 018 creates the index that 019 renames, and your order keeps 018 before 019 so that holds. build, typecheck and the full suite (215 tests) all pass locally. merging.

if you want to keep contributing, join us on Telegram: https://t.me/+DOylgFv1jyJlNzM0