Ballerina persist clients and the relational database: who owns rollback safety after a generated schema change is applied?

We use Ballerina's persist feature to generate type-safe data-access clients and SQL migration scripts from a Ballerina data model, backed by a relational store (PostgreSQL in our case, with MySQL in some environments). Applying model changes forward works well, but the persist tooling does not appear to generate down-migrations or any automated rollback path.

The boundary that concerns us is version skew: a persist client is bound to the model version it was generated from. If we roll back the Ballerina service code without rolling back the schema, or roll back the schema while the new client is still deployed, the two supported components disagree about the model. On PostgreSQL we can wrap DDL in a transaction, but on MySQL the implicit-commit behavior of DDL makes that unreliable, so a single rollback strategy may not be portable across our targets.

We are deciding whether to keep generated scripts under version control and hand-write compensating scripts per change, or delegate migration ordering and rollback to an external tool such as Flyway or Liquibase while persist only generates the forward SQL.

Is there a documented or recommended pattern for pairing persist-generated migrations with rollback artifacts, or is this explicitly out of scope for the tooling? How do teams prevent client/schema version skew during a partial rollback at this boundary? Does the answer change materially between PostgreSQL and MySQL given their different DDL transaction semantics?