feat: add strong_migrations gem to prevent unsafe migration deploys

[mroderick]

What

Adds the strong_migrations gem to block dangerous migration patterns before they reach production.

Scope

• Checks all migrations from 2026-01-01 onwards (start_after = 20260101000000)
• Targets PostgreSQL 16 (Heroku production version)
• Active in all environments including test (catches issues in CI)

Existing violations acknowledged

Six 2026 migrations already deployed contain patterns strong_migrations flags. Each is wrapped in safety_assured { ... } — no logic changes, just marking them as reviewed:

• execute with DELETE for duplicate cleanup
• update_all inside a schema migration for data backfill
• add_index without algorithm: :concurrently
• remove_index without algorithm: :concurrently
• drop_table on meeting_talks
• Data cleanup loops (delete_all) inside schema migrations

Reviewer hint: it's a lot easier to review this part of the PR, if you hide the whitespace changes 😄

What this prevents going forward

• Adding non-nullable columns without defaults to existing tables
• Adding indexes without algorithm: :concurrently on large tables
• Data backfills inside schema migrations
• drop_table / remove_column without a staged removal process
• Raw execute SQL without review

[mroderick]

@olleolleolle do you think it makes sense to fix all the existing migrations, going all the way back to the dawn of time?

[olleolleolle]

@mroderick At work, we ditch migration files we have used up, after some time. We rely on db/schema.rb instead, rather than a group of migration files in order.

So, a step could be: find a migration file that needs a fix, and remove it AND its predecessors.

[mroderick]

At work, we ditch migration files we have used up, after some time. We rely on db/schema.rb instead, rather than a group of migration files in order.

So, a step could be: find a migration file that needs a fix, and remove it AND its predecessors.

So, you keep the migrations around in case you need to run the down migration, and once you're confident that you don't, you remove them?

Do you use tools like squasher (unmaintained)?

[olleolleolle]

At work, we ditch migration files we have used up, after some time. We rely on db/schema.rb instead, rather than a group of migration files in order.
So, a step could be: find a migration file that needs a fix, and remove it AND its predecessors.

So, you keep the migrations around in case you need to run the down migration, and once you're confident that you don't, you remove them?

Yeah, something like that - we don’t have a schedule for these “lose the migration files” events. We do it when it “feels right”.

Do you use tools like squasher (unmaintained)?

We don’t use a squasher tool.