Making dbm-rollback safe after destructive schema changes in the Grails database-migration plugin

Our Grails application uses the database-migration plugin (Liquibase-based) with changelogs under grails-app/migrations, and we are standardizing how schema changes ship to production. The goal is a rollback story that actually works when a release must be reverted, not just one that exists on paper.

The uncertainty is around destructive changeSets. Liquibase can auto-generate rollback for additive changes like createTable or addColumn, but dropColumn, dropTable, and raw sql changeSets either need explicit rollback blocks or cannot restore dropped data at all. We also generate initial drafts with dbm-gorm-diff, and those diffs appear to lack rollback definitions by default. Additionally, some environments still run with dbCreate set to update, which may let Hibernate alter the schema outside Liquibase's tracking and make rollback ordering unreliable.

Assume a recent Grails 5/6 line with the matching database-migration plugin; exact plugin version compatibility still needs confirmation against the documented matrix.

Specific questions:

1. For destructive changes, is expand-and-contract (add new schema, migrate data, drop old schema in a later release) the only safe pattern, or is there a supported way to make drop changeSets revertible?
2. Should dbCreate be set to none or validate in every environment once migrations are adopted, and what breaks if it stays update during a rollback?
3. When rollback must recover dropped data, do teams rely on database snapshots/restore instead of dbm-rollback, and how is that coordinated with the DATABASECHANGELOG table?