dbCreate in production: validate with manual SQL or the Database Migration plugin?

I have a Grails application where the development environment uses dbCreate: update, so Hibernate builds and evolves the schema automatically while running locally. For the production environment, the documented guidance is effectively to avoid auto-generation, which leaves an open decision about how the production schema should actually be created and kept in sync with the domain model.

The constraints I am weighing: GORM's update mode does not drop columns and does not apply every constraint change reliably, so a production schema evolved that way can silently diverge from what a fresh local create-drop schema looks like. The two documented paths appear to be dbCreate: validate combined with hand-written SQL, or adopting the Grails Database Migration plugin (Liquibase-based) and managing changelogs. The framework documents both but does not mandate either.

My questions:

1. For a team already comfortable with GORM, is validate plus the migration plugin the generally accepted production setup, or are there cases where manual SQL alone is preferred?
2. When moving an existing production database (previously managed with update) to the migration plugin, what is the correct way to baseline the current schema so changelogs only apply from that point forward?
3. Does the answer change across Grails versions, given that configuration defaults and plugin compatibility differ between major releases?