Behavior of `bal persist pull` when database schema undergoes destructive changes

Goal: Understand the expected behavior of the bal persist pull command when the underlying relational database has experienced destructive changes such as dropped tables or columns after the persistence model was initially generated.

Constraint: The persistence model produced by bal persist pull is treated as regenerable output and is overwritten on each invocation, so any manual edits to the generated .bal files are lost. The current documentation does not explicitly state whether the tool should silently remove corresponding entity definitions, emit a warning, or fail when it detects that a table or column no longer exists in the database, creating uncertainty about safe recovery semantics for data that was previously persisted.

• Should bal persist pull silently delete entity definitions that correspond to dropped tables or columns?
• Should it emit a warning and retain the stale definitions, requiring manual cleanup?
• Should it treat the mismatch as an error and halt the pull operation until the model is reconciled?