[costajohnt]

Closes #2963

With preboot, the release phase runs before old web dynos stop, so old code serves against the new schema for about 3 minutes after each deploy. strong_migrations' destructive-operation messages don't say that, so the preboot guidance in AGENTS.md ("Migrations and Heroku preboot") is invisible at the moment someone hits the error.

This appends a short preboot note to the nine messages listed in the issue, through StrongMigrations.error_messages (the gem's documented custom-messages API). The gem's own text is unchanged and comes first; the note goes after it. It uses fetch, so if a future gem version drops one of these keys, boot fails loudly instead of the note silently landing on nil.

I left remove_column, change_column_null_postgresql (what change_column_null without a default raises on Postgres 16) and add_column_default out, since the issue scoped the list. AGENTS.md mentions remove_column and adding a column with a default as preboot hazards too, so I'm happy to add them here if you'd like.

Testing

• New spec/config/strong_migrations_config_spec.rb: the rename_column message still starts with the gem's text and ends with the note, all nine messages carry the note exactly once, and an unrelated message (add_index) is unchanged. Two of the three examples fail without the initializer change.
• The issue's manual check: a throwaway rename_column migration run with bin/rails db:migrate in development prints the gem's message followed by the note. Of the 35 messages, 9 carry the note and the other 26 are unchanged.
• bundle exec rspec (1748 examples, 0 failures) and bundle exec rubocop on the changed files.