Deta Space Collections and Space Apps: Can Schema Migrations Roll Back Safely?

Goal: Determine whether an application-level schema migration from a Deta Space App can be reversed in Deta Space Collections without corrupting document shapes or losing writes accepted after the migration starts.

Collections are schema-less, while Space Apps declare Collection access but provide no documented migration registry, transaction spanning documents or collections, or deploy-time rollback hook. A Space snapshot is a coarse rollback boundary: restoring it may discard intervening writes across the Space. Collection triggers are asynchronous, and concurrent app versions may read or write different document shapes.

This question applies to the currently documented Collections, Space Apps, and Node, Python, and Go SDK interfaces. The relevant verification boundary is a two-Collection test Space with concurrent app versions and trigger events; snapshot, trigger, and consistency semantics should be checked against the target Space release before relying on them.

Can a Space App coordinate a versioned backfill with a rollback that preserves writes accepted during migration? Does snapshot restore provide a usable compatibility boundary for two app versions? Can already-delivered trigger events be reconciled after a restore without assuming replay or suppression?